invoice-management

請求書管理

概要

このスキルでは、ServiceNow Sourcing and Procurement Operations における買掛請求書の管理方法を体系的に説明します。次の作業に役立ちます。

• sn_proc_invoice テーブルから請求書データを抽出して検証する
• 三点照合（PO、検収、請求書）を使用して、請求書と発注書を照合する
• 請求金額、PO 金額、検収数量の不一致を特定する
• sn_apo_invoice_case を使用して、請求書の例外ケースを作成し、割り当てる
• 請求書の承認ワークフローと支払い準備状況を追跡する

使用するタイミング： 請求書の確認、発注書および入荷検収との照合、または不一致の調査と解決が必要な場合に使用します。

前提条件

• ロール： sn_procurement.invoice_manager、sn_procurement.analyst、または accounts_payable
• プラグイン： com.sn_procurement（Sourcing and Procurement Operations）が有効化されていること
• アクセス権： sn_proc_invoice、proc_po、proc_po_item、proc_rec_slip_item への読み取り／書き込みアクセス権
• 知識： 三点照合の原則と、組織の許容しきい値に関する理解

手順

ステップ 1：処理待ちの請求書を照会する

処理または照合を待っている請求書を取得します。

MCP を使用する場合（Claude Code/Desktop）：

Tool: SN-Query-Table
Parameters:
  table_name: sn_proc_invoice
  query: state=pending^ORstate=awaiting_match
  fields: sys_id,number,vendor,po_number,invoice_amount,invoice_date,currency,state,due_date
  limit: 25
  order_by: due_date

REST API を使用する場合：

GET /api/now/table/sn_proc_invoice?sysparm_query=state=pending^ORstate=awaiting_match^ORDERBYdue_date&sysparm_fields=sys_id,number,vendor,po_number,invoice_amount,invoice_date,currency,state,due_date&sysparm_limit=25

ステップ 2：関連付けられた発注書を取得する

各請求書について、照合を開始するために関連付けられた PO とその明細を取得します。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: proc_po
  query: number=[PO_NUMBER]
  fields: sys_id,number,vendor,total_cost,state,ordered_date,expected_delivery,currency
  limit: 1

次に、PO の明細を取得します。

Tool: SN-Query-Table
Parameters:
  table_name: proc_po_item
  query: purchase_order.number=[PO_NUMBER]
  fields: sys_id,item_description,quantity,unit_price,total_cost,received_quantity,model,part_number
  limit: 50

REST API を使用する場合：

# Get PO header
GET /api/now/table/proc_po?sysparm_query=number=[PO_NUMBER]&sysparm_fields=sys_id,number,vendor,total_cost,state,ordered_date,expected_delivery,currency&sysparm_limit=1

# Get PO line items
GET /api/now/table/proc_po_item?sysparm_query=purchase_order.number=[PO_NUMBER]&sysparm_fields=sys_id,item_description,quantity,unit_price,total_cost,received_quantity,model,part_number&sysparm_limit=50

ステップ 3：入荷検収記録を取得する

検収明細を照会し、実際に受領した数量を確認します。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: proc_rec_slip_item
  query: purchase_order.number=[PO_NUMBER]
  fields: sys_id,quantity_received,received_date,po_item,receiving_slip,condition,notes
  limit: 50

REST API を使用する場合：

GET /api/now/table/proc_rec_slip_item?sysparm_query=purchase_order.number=[PO_NUMBER]&sysparm_fields=sys_id,quantity_received,received_date,po_item,receiving_slip,condition,notes&sysparm_limit=50

ステップ 4：三点照合を実施する

3 つの書類を照合します。明細ごとに、次の項目を検証します。

1. 数量照合： 請求書数量 <= 検収数量 <= 注文数量
2. 価格照合： 請求書の単価 == PO の単価（許容範囲内。通常は 1～5%）
3. 合計金額照合： 請求書合計 <= PO 合計（許容範囲内）

確認項目	計算式	合格条件
数量	invoice_qty <= received_qty	請求書数量が検収数量を超えていない
単価	abs(invoice_price - po_price) / po_price * 100	差異がしきい値以内（例：2%）
明細合計	invoice_line_total <= po_line_total * (1 + tolerance)	許容範囲内
請求書合計	invoice_total <= po_total * (1 + tolerance)	総合計が許容範囲内

ステップ 5：不一致にフラグを付け、割り当てる

照合に失敗した場合は、解決のために請求書の例外ケースを作成します。

MCP を使用する場合：

Tool: SN-Create-Record
Parameters:
  table_name: sn_apo_invoice_case
  fields:
    invoice: [invoice_sys_id]
    purchase_order: [po_sys_id]
    short_description: "Three-way match failure: quantity discrepancy on PO0012345"
    description: "Invoice INV-9876 line 2: invoiced qty 100, received qty 85. Variance: 15 units (17.6%). Exceeds 5% tolerance threshold."
    priority: 2
    category: quantity_discrepancy
    state: new
    assigned_to: [procurement_analyst_sys_id]

REST API を使用する場合：

POST /api/now/table/sn_apo_invoice_case
Content-Type: application/json

{
  "invoice": "[invoice_sys_id]",
  "purchase_order": "[po_sys_id]",
  "short_description": "Three-way match failure: quantity discrepancy on PO0012345",
  "description": "Invoice INV-9876 line 2: invoiced qty 100, received qty 85. Variance: 15 units (17.6%).",
  "priority": "2",
  "category": "quantity_discrepancy",
  "state": "new"
}

ステップ 6：請求書の状態を更新する

照合結果に基づいて、請求書を照合済みまたは例外としてマークします。

MCP を使用する場合：

Tool: SN-Update-Record
Parameters:
  table_name: sn_proc_invoice
  sys_id: [invoice_sys_id]
  fields:
    state: matched
    match_status: passed
    work_notes: "Three-way match completed. All line items within tolerance. Ready for payment approval."

照合に失敗した場合：

Tool: SN-Update-Record
Parameters:
  table_name: sn_proc_invoice
  sys_id: [invoice_sys_id]
  fields:
    state: exception
    match_status: failed
    work_notes: "Three-way match failed. Exception case CASE0045678 created for quantity discrepancy on lines 2, 5."

REST API を使用する場合：

PATCH /api/now/table/sn_proc_invoice/[invoice_sys_id]
Content-Type: application/json

{
  "state": "exception",
  "match_status": "failed",
  "work_notes": "Three-way match failed. Exception case created."
}

ツールの使用方法

MCP ツールのリファレンス

ツール	使用するタイミング
SN-Query-Table	請求書、PO、検収記録、仕入先を照会する
SN-Natural-Language-Search	仕入先または金額で請求書を自然言語検索する
SN-Create-Record	請求書の例外ケースを作成する
SN-Update-Record	請求書の状態と照合ステータスを更新する
SN-Add-Work-Notes	照合結果と判断を記録する

REST API リファレンス

エンドポイント	メソッド	目的
/api/now/table/sn_proc_invoice	GET	請求書を照会する
/api/now/table/sn_proc_invoice/{sys_id}	PATCH	請求書のステータスを更新する
/api/now/table/proc_po	GET	発注書を取得する
/api/now/table/proc_po_item	GET	PO の明細を取得する
/api/now/table/proc_rec_slip_item	GET	入荷検収記録を取得する
/api/now/table/sn_apo_invoice_case	POST	例外ケースを作成する

ベストプラクティス

• 許容しきい値の設定： カテゴリごとに許容できる差異率を定義します（例：IT ハードウェアは 2％、オフィス用品は 5％）
• 期日順の優先処理： 延滞料金を避けるため、支払期日が近い請求書から処理します
• ベンダー詳細の確認： core_company のレコードと照合し、支払い前にベンダーの銀行口座情報を確認します
• バッチ処理： 効率的な照合ワークフローのため、請求書をベンダー別または PO 別にグループ化します
• 監査証跡： コンプライアンスのため、照合結果を記録した作業メモを必ず追加します
• 部分受領： 一部出荷の場合は、受領済みの数量のみ照合し、残りは保留します

トラブルシューティング

「請求書にリンクされた発注書がありません」

原因： PO 番号フィールドが空、または一致しない参照が含まれています 解決策： ベンダーと日付範囲を指定して proc_po を検索し、正しい PO を見つけて請求書レコードを更新します

「入庫記録が見つかりません」

原因： ServiceNow にまだ入庫が記録されていません 解決策： PO を指定して proc_rec_slip_item を確認します。倉庫に連絡して実際の受領を確認し、入庫伝票を作成します

「請求書の金額が PO の合計を超えています」

原因： 価格の上昇、追加料金（送料、税金）、または請求書の重複 解決策： 例外ケースを作成し、請求内容が正当かベンダーに確認します。sysparm_query=vendor=[vendor_id]^invoice_amount=[amount]^invoice_date>=[date] を使って請求書の重複を確認します

「1 枚の請求書に複数の PO があります」

原因： ベンダーが複数の注文を 1 枚の請求書にまとめています 解決策： 請求書を分割するか、部品番号または品目の説明を使って、個々の PO と明細ごとに照合します

例

例 1：3 点照合の成功

シナリオ： Acme Corp からの請求書 INV-2024-0456、金額は $15,000.00

手順：

1. 請求書を照会します：金額は $15,000、PO0012345 にリンクされています
2. PO0012345 の合計：$15,000、明細は 3 件
3. proc_rec_slip_item によると、3 件すべての品目を全数受領済みです
4. 価格差異：すべての明細で 0％
5. 結果：照合に合格

Tool: SN-Update-Record
Parameters:
  table_name: sn_proc_invoice
  sys_id: a1b2c3d4...
  fields:
    state: matched
    match_status: passed
    work_notes: "Three-way match passed. PO0012345 fully received. All prices match. Ready for payment."

例 2：解決が必要な不一致

シナリオ： 請求書 INV-2024-0789 には、単価 $12.00 で 500 個（$6,000）と記載されています。PO には、単価 $10.00 で 500 個（$5,000）と記載されています。入庫記録では 500 個の受領が確認されています。

分析：

• 数量：一致（500 = 500）
• 単価：$12.00 対 $10.00 = 20％の差異（しきい値の 2％を超過）
• 合計：$6,000 対 $5,000 = $1,000 の超過

対応： 例外ケースを作成し、調達アナリストによる確認のためにフラグを付け、支払いを保留します。

例 3：部分受領の照合

シナリオ： 1,000 個の PO に対して 750 個を受領し、請求書は 750 個分です。

分析：

• 請求書の数量（750）は受領済み数量（750）と一致しています
• 請求書の数量は PO の数量（750 <= 1,000）を超えていません
• 結果：部分照合に合格 -- 750 個分の請求書を承認できます

関連スキル

• procurement/purchase-order-summarization - PO の詳細と納品状況を要約します
• procurement/procurement-summarization - 調達ケースとパイプラインの概要
• procurement/supplier-recommendation - 調達先の選定に向けてベンダーの実績を評価します
• catalog/approval-workflows - 請求書の承認ワークフローを設定します