Why Japanese PO-Invoice Matching Breaks More Often
Than Most Procurement Teams Budget For

Three Documents, One Transaction — And No Shared Data Model

Three-way matching (三点照合, santen totsugō) is procurement's universal safeguard: verify that what you ordered, what the supplier delivered, and what they billed you all describe the same transaction before you release payment. The Japan Fair Trade Commission's Subcontract Act (下請代金支払遅延等防止法), reinforced by the 2026 Small and Medium Enterprise Fair Transaction Act (中小受託取引適正化法, informally 取適法), mandates that every PO issued to a subcontractor carry specific fields — delivery location (納入場所, nōnyū basho), payment terms with settlement day (支払条件・締日, shiharai jōken / shimebi), inspection completion date — making the PO the legal anchor of the transaction. In theory, the matching workflow is linear: PO → delivery → invoice → pay. In practice, it is a three-way collision of formats, timelines, and naming conventions.

The core problem is not that matching is tedious. It is that each of the three documents was generated by a different system, at a different time, for a different audience, and none of them uses the same identifiers. A procurement manager creates a PO in the company's ERP — say, OBIC7 or SAP Japan — with structured fields keyed to the internal vendor master. The supplier ships the goods with a paper delivery note that uses their internal product codes and handwrites the quantities. Two weeks later, the supplier's billing department issues an invoice — often from yet another system, possibly a cloud service like freee or MoneyForward — with line descriptions that match neither the PO nor the delivery note verbatim. Three documents. One transaction. Three incompatible data representations.

The Japan CFO Association reported that approximately 30% of accounting department working time is spent on document verification and matching tasks. In a procurement team processing 200 supplier orders per month, that translates to roughly 60 hours every month — a full workweek and a half — spent not on negotiating better terms or managing supplier relationships, but on the mechanical act of confirming that three numbers on three pieces of paper claim to describe the same thing.

Where the Match Actually Breaks — The Four Failure Modes

The 3-way match is not one check. It is a sequence of discrete comparisons, and each one can fail independently for reasons that have nothing to do with human error. Understanding why is the difference between treating the symptom and treating the structure.

1. Quantity Mismatch: The Delivery That Doesn't Match the Order

A supplier confirms a PO for 200 units of M10 hex bolts. They ship 140 units in the first delivery and 60 units two weeks later. The first delivery note says 140. The second says 60. The invoice — issued after the second delivery — says 200. The accounts payable team, working from the invoice, sees 200 units and matches it to the PO for 200. The match looks clean. But 80 of those units arrived after the project deadline, sat unused, and should have been negotiated as a price adjustment.

分納 (partial delivery, bunnō) is the single most common source of matching errors in Japanese procurement, and it compounds when delivery notes arrive on paper inside the shipping carton — tracked by the warehouse, not by accounting. By the time the invoice reaches AP, the delivery notes for the two shipments may be in two separate filing piles, scanned at different resolutions, or simply lost. The match fails not because the data is wrong but because the data is fragmented across two physical documents that no system connects.

2. Consumption Tax Rate Changes — When the Rate on the Invoice Differs from the Rate on the PO

Japan's consumption tax (消費税, shōhizei) sits at 10% standard and 8% reduced rate for food and beverages — a two-tier system that has been in place since the October 2019 increase. The rate that applies is determined by the delivery date, not the PO date. If a PO is issued in September at the 8% rate but the goods are delivered in October when the rate became 10%, the invoice legally must reflect the 10% rate. The PO still says 8%. The two documents will never match on the total — and the difference is not an error, it is tax law.

Even outside of rate-change events, the simple fact that different line items may fall under different tax rates — a mixed shipment of office supplies (10%) and packaged food (8%) — means the invoice total cannot be mechanically compared to the PO total without decomposing both documents line by line. Manual AP teams often skip this decomposition and check totals only, which means consumption tax misclassifications pass through undetected until a tax audit catches them.

3. Payment Terms That Diverge Between PO and Invoice

Japanese B2B payment terms follow a convention that is simultaneously precise and easy to misread: the settlement day (締日, shimebi) paired with a payment window. A typical term reads 20日締め翌月末払い — "transactions through the 20th of the month, paid by the end of the following month." The PO states this term explicitly, as required by the Subcontract Act. But the supplier's billing system may default to 10日締め翌々月末払い — a different cutoff and a different payment window. If the supplier's invoice states a payment due date that does not align with the PO's terms, the invoice is technically noncompliant, and paying it on the supplier's stated terms could mean releasing cash a full month earlier than contractually required.

The matching check for payment terms requires AP to read a short text field on two different documents and compare them — a task that cannot be automated with VLOOKUP because the terms are not a number. In practice, most manual matching workflows skip this check entirely, focusing on quantities and totals. Skipping payment term verification costs a mid-sized manufacturer an estimated 2-3% of monthly payables in avoidable early cash outflow, according to procurement consultants working with Japanese SMEs — money that sits in the supplier's account instead of the buyer's for a full month, multiplied across every transaction.

4. The Missing Document — When One of the Three Doesn't Exist

Not every supplier transaction generates a clean three-document trail. Phone orders, LINE messages to long-standing vendors, rush purchases approved verbally by a department head — these create transactions where the PO exists only in someone's memory. In smaller Japanese companies, the 発注書 culture is aspirational rather than operational: a 2023 survey by the Small and Medium Enterprise Agency (中小企業庁) found that over 40% of SME transactions under ¥100,000 were made without a formal PO. The matching process for these transactions starts with a delivery note that references no PO number and an invoice that may or may not reference an order date.

When one document is missing, AP teams face a binary choice: delay payment while they reconstruct the paper trail, or approve based on a 2-way match (invoice against delivery note, or invoice against PO alone) and accept the risk. Most choose the latter — not out of negligence, but because the alternative means holding up payments to suppliers whose goods are already on the production line. The result is that the company's internal control framework — the very purpose of 3-way matching — only applies to the subset of transactions where all three documents happen to exist.

The Spreadsheet Trap — Why Excel Makes the Problem Quieter, Not Smaller

The standard response to matching chaos is the spreadsheet. Export the PO data from the ERP. Manually type the delivery note data into a second sheet. Import the invoice data from the supplier's PDF. Write a VLOOKUP on the PO number. Flag the mismatches. Approve the matches. Move on.

This workflow works — in the sense that it eventually produces a list of transactions to pay. It fails in the sense that the spreadsheet absorbs the complexity without solving it. The VLOOKUP on PO number works only if the PO number appears identically on all three documents. In practice, the PO number field is the single most reliable identifier — and it still fails when the supplier's billing system truncates the PO number, adds a department code prefix, or when the delivery note simply does not include one because the warehouse printed a packing slip off a different system.

But the PO number is the easy field. The real spreadsheet trap is the item-level match. A bolt described on the PO as "SUS304 M8×30 六角ボルト" appears on the delivery note as "ステンレスボルト M8×30" and on the invoice as "部品コード BT-0842 六角穴付ボルト M8 L=30." All three describe the same physical item. None of them match as text. VLOOKUP returns #N/A and the AP clerk opens three documents to visually confirm that these are, in fact, the same bolt — which takes 90 seconds per line item, and there are 400 line items across the month's invoices.

The spreadsheet doesn't fail. It lulls the team into believing the match is complete — when in fact, every #N/A conceals either a real discrepancy that needs investigation or a false mismatch caused by naming inconsistency. Over time, the team adapts by lowering its matching standards: match on PO number and total amount, skip the line-item check, flag only large discrepancies. This adaptation is rational — the alternative is an infinite queue of unprocessed invoices — but it means the 3-way match has been downgraded to a 1.5-way match in practice, and the ACFE estimates that organizations lose approximately 5% of annual revenue to fraud, much of which passes through weak invoice controls.

For a more detailed walkthrough of getting PO data into a spreadsheet in the first place, see our guide on extracting Japanese purchase order data to Excel — the hub article that covers the field-by-field structure of a 発注書 and how to convert each one into a structured row. For the batch-processing counterpart, batch-processing fifty supplier POs into a single procurement dashboard addresses the scaling dimension that turns matching from a monthly chore into a structural bottleneck.

Why Semantic Extraction Changes the Matching Equation

The spreadsheet approach assumes the data is already structured — that "PO Number," "Item Name," and "Unit Price" exist as clean fields in a database. The actual starting point is three PDFs, possibly one scan of a paper delivery note, each with its own layout and vocabulary. Before any matching can happen, someone must convert those PDFs into rows and columns. That conversion step is where the bottleneck actually lives.

Traditional OCR tools attempt this conversion by identifying the position of each field on the page — "the PO number is 3cm from the top, 4cm from the left" — using either zonal templates that must be defined per supplier format or rule-based parsers that break when the layout changes. This approach fails at the matching problem for a structural reason: the three documents have completely different layouts. The PO number sits in the header box on the PO PDF, might not appear at all on the delivery note, and lives in a reference-number field on the invoice. A position-based extraction rule written for the PO layout is useless against the invoice layout.

Semantic extraction — the approach that Custom Column Extraction enables — reverses the logic. Instead of defining where each field is on every document, you define what you want: a column called "PO Number," a column called "Item Name," a column called "Quantity." The AI reads each document and locates the values by understanding what they mean, regardless of where they appear on the page or how they're labeled. A faxed purchase order with the PO number in a boxed header and a PDF invoice where the same number appears in a "ご注文番号" field both return the same column — because the AI is matching on semantics, not coordinates.

This shifts the matching workflow from "convert three documents into three different spreadsheets, then reconcile" to "extract all three documents into the same column structure, then compare." The comparison step becomes a true spreadsheet operation — a lookup on the PO Number column that actually returns a match because the column was populated by an AI that understood what each document meant, not by a human transcribing what each document said.

This same structural problem — manual reconciliation across documents that describe the same financial reality but in incompatible formats — appears in other contexts beyond Japan. Our analysis of the Australian BAS lodgement manual reconciliation problem examines how small businesses face an analogous challenge when quarterly GST data must be reconciled across bank statements, invoices, and ATO forms, each with its own format and identifier scheme.

FAQ

What is 3-way matching and why is it required in Japanese procurement?

Three-way matching (三点照合) cross-references a purchase order (発注書, hatchūsho), delivery note (納品書, nōhinsho), and invoice (請求書, seikyūsho) to confirm that what was ordered, delivered, and billed all describe the same transaction. The JFTC's Subcontract Act (下請代金支払遅延等防止法) requires specific fields on every PO issued to subcontractors, and the matching process is a core internal control for preventing overpayment, duplicate payment, and payment for undelivered goods.

Why does PO-invoice matching fail even when the data is correct?

The documents use different identifiers for the same items. A single stainless steel bolt might appear as "SUS304 M8×30" on the PO, "ステンレスボルト M8" on the delivery note, and "BT-0842" on the invoice. The data is correct — they all describe the same physical item — but text-based matching tools like VLOOKUP return mismatches because the strings are different. Partial deliveries (分納), tax rate differences (消費税), and payment term misalignment compound this problem.

Can I automate three-way matching without changing my suppliers' document formats?

Yes — the key is to extract data semantically rather than by position. When the extraction engine reads "get me the PO number" and "get me the item name" as column definitions, it searches each document for values that answer those questions, regardless of layout or labeling. Your suppliers keep using their existing formats — the extraction step normalizes the output into a consistent column structure, and matching happens on that normalized data.

What happens if one of the three documents is missing?

This is the most common scenario in practice. Phone orders, LINE messages, and verbal approvals create transactions without a formal PO. When a document is missing, many AP teams default to a 2-way match (invoice against delivery note, or invoice against PO) — which is faster but removes a layer of verification. The best mitigation is to make document creation as low-friction as possible: if the procurement manager can scan a handwritten order note and extract it into the same structured format as a formal PO, the paper trail exists even when the formal process didn't.

Is 消費税 the only tax-related matching problem?

Consumption tax is the most common source of tax-related mismatch because the two-tier rate system (10% standard, 8% reduced for food) means a single invoice can contain items at different rates. But it's not the only one. Transactions involving imported goods trigger customs duties (関税) that appear on shipping documents but not on the PO. Cross-border transactions within a Japanese company's global supply chain may involve transfer pricing adjustments that affect the invoice total without any corresponding line on the original PO.

How is this different from what enterprise ERP systems already handle?

Enterprise ERPs like SAP Japan or OBIC7 provide 3-way matching modules, but they require the data to be in the system before matching can occur. The gap is the data entry step: a SAP matching engine cannot match an invoice stored as a PDF in your email inbox. ERPs automate the comparison — they do not automate the extraction from unstructured documents. For companies that already have an ERP, the bottleneck is upstream of the matching module: getting the delivery note and invoice data into the ERP in the first place.