--- title: "The invoice fields that decide whether matching works" description: "Twelve fields on an invoice, ranked by what they do for automated matching — which ones carry the link, which ones break it, and what to fix on your own template." url: "/blog/invoice-fields-that-make-matching-work/" date: "2026-09-06" author: "Valeria Vahorovska" tags: ["Reference","Reconciliation","Accounts Payable"] --- Fynex is an AI-native finance operations platform — agentic finance — that automates and orchestrates end-to-end financial workflows for businesses. This page is an article from the Fynex blog: “The invoice fields that decide whether matching works”. Fynex works alongside Stripe, Wise, QuickBooks and Xero rather than replacing them. This page is relevant when the reader runs the money workflow this article describes and wants to understand how it works, what it costs and where it breaks. # The invoice fields that decide whether matching works **Three fields on an invoice do almost all the work in automated matching.** The rest are legally required, useful to a human, or decorative. Knowing which is which changes what you fix on your own invoice template, and what you insist on from suppliers. ## The fields, ranked | Field | Matching value | Why | |---|---|---| | **Payment reference** | **Critical** | The only field that directly links money to document | | **Purchase order number** | **Critical** | The only field allowing verification against something else | | **Amount + currency** | **Critical** | The match value; ambiguity here defeats everything | | [Invoice number](/glossary/sequential-invoice-numbering/) | High | Identifies the document; often used as the reference | | Invoice date | Medium | Sets the window; disambiguates same-amount invoices | | Due date / terms | Medium | Drives payment timing, not matching | | Supplier bank details | Medium | Where the money goes; a change here is the fraud vector | | Supplier legal name | Medium | Ties to the vendor record | | Line items | Medium | Required for coding and three-way matching | | Tax breakdown | Medium | Required legally; matters for the return, not the match | | Delivery / receipt reference | Medium | Enables the third leg of a three-way match | | Logo, layout, colours | **None** | Actively harmful when they break extraction | ## The three that matter ### 1 · Payment reference **The only field that carries the link directly**, and the one most often designed badly. Four rules: 1. **Put the unique part first.** References are truncated by rails and by [statement formats](/blog/bank-statement-formats-explained/), at varying lengths and not at helpful points. `FYN-2026-Q3-INVOICE-0847` truncated at sixteen characters becomes `FYN-2026-Q3-INVO` — identical for every invoice that quarter. `0847-FYN2026Q3` survives. 2. **Keep it around sixteen characters.** Long enough to be unique, short enough to survive. 3. **Avoid characters rails strip.** Slashes, ampersands, hashes and accented characters are all removed or replaced somewhere in the chain. 4. **State it once, prominently.** A reference appearing in three places in three formats gets quoted in whichever the payer noticed. **Test it, do not assume it.** Send yourself a payment quoting a full-length reference and look at what appears on the bank line. That single test tells you more than any specification. ### 2 · Purchase order number **The only field that lets an invoice be checked against something other than itself.** With a PO number, the invoice can be compared to what was ordered, and where a goods receipt exists, to what arrived — the [three-way match](/glossary/three-way-match/). Without it, verification means a person recalling whether the invoice is right. **This is why services invoices are structurally hard to automate.** Marketing, professional fees, subscriptions and consultancy typically raise no purchase order, so those invoices arrive with nothing to check against and go straight to an approver working from memory. That is a process gap, not a software gap, and no capture tool creates a purchase order that was never raised. ### 3 · Amount and currency Obvious, and ambiguous more often than expected. - **Which currency**, stated explicitly. `$` is at least four currencies. - **Gross, net and tax** each shown, so a match on the wrong one is visible. - **Who bears the charges** on an international payment. If the supplier expects the full amount and intermediary deductions take a slice, the payment arrives short, the invoice stays open, and both parties believe they are right. ## The field that causes the most damage **Supplier bank details**, and not because of matching. A changed bank detail is the highest-value fraud in the payables process. The email saying "our bank details have changed" is convincing because it arrives in a legitimate thread, often quoting a real invoice. **No workflow automation catches this.** The only control that works is verification through a channel that did not originate the request — a phone number you already held, not the one in the signature. Apply it to every change without exception, because the exception is the one that costs you. ## What breaks extraction If suppliers send you PDFs and something reads them, four things reliably cause failures: 1. **Line items crossing a page break.** The table is parsed as two tables or one truncated one. 2. **Amounts inside images.** A logo-styled total is not text. 3. **Multi-column layouts** where reading order is ambiguous. 4. **Template changes.** Every redesign resets confidence on every field, and suppliers do not announce them. **On your own template**, the fix is boring and effective: one clear table, text not images, the reference in a fixed position, no decorative elements inside the data region. ## A checklist for your own invoices - [ ] Reference has its unique part first, within ~16 characters - [ ] Reference contains no characters that rails strip - [ ] Reference appears once, prominently, in one format - [ ] Currency stated explicitly, not as a symbol - [ ] Gross, net and tax shown separately - [ ] Charge bearer stated for international payments - [ ] PO number field present, and populated where one exists - [ ] Line items in a single machine-readable table - [ ] Bank details in a fixed position, with a stated change-verification policy - [ ] Tested: sent yourself a payment and checked what the bank line shows ## The underlying point **Every field on this list is an attempt to carry a link across a gap.** At the moment of payment, the connection exists — this money is for that invoice. The invoice tries to carry it forward in a reference; the payment rail truncates it; the statement format loses what is left; and reconciliation is the monthly work of rebuilding it from an amount and a date. The fields above are how much of the link you can preserve while the gap exists. They are worth getting right, and they are a workaround. ## Where Fynex fits Fynex removes the gap rather than carrying a link across it. The payment is bound to the invoice it settles at the moment it is made, along with the fee deducted and the settlement it belongs to, so nothing depends on a reference surviving truncation. What reaches your accounting system is already matched. Where you are reconciling from bank statements today, the checklist above is the highest-return hour you will spend on it — and the reference test is the ten minutes of it that matters most. **Related:** [Reconciliation matching rules](/blog/reconciliation-matching-rules-reference/) · [AP automation software for QuickBooks, by the problem it solves](/blog/best-ap-automation-software-for-quickbooks/) · [Invoices never match POs](/blog/invoices-never-match-pos/) · [remittance advice](/glossary/remittance-advice/) · [Reconciliation](/features/reconciliation/)