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

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, 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. 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 · Invoices never match POs · remittance advice · Reconciliation