Automating invoice reconciliation, build vs buy

Invoice reconciliation automation means letting software match invoices against purchase orders and delivery confirmations, clear the records that agree, and send only the real discrepancies to a person. Done well, your team stops checking every line and starts working on exceptions only.

Whether you should buy a tool or build your own depends on where your data lives and how unusual your matching rules are. If your purchase orders, receipts and invoices are all in one ERP with standard rules, buy. If the evidence is spread across several systems, carriers and suppliers, or your rules are specific to your industry, a custom build is often cheaper and fits better.

What invoice reconciliation actually involves

Reconciliation checks that you are paying for what you ordered and what you received. There are two common levels.

2-way match

The invoice is compared with the purchase order (PO): same supplier, same items, same quantities, same unit prices. This catches price errors and invoices for things nobody ordered. It is common for services, where there is no physical delivery to confirm.

3-way match

The invoice is compared with the PO and with proof of delivery: a goods receipt in the warehouse system, or a shipping and delivery confirmation from a carrier. This adds a third question: did it actually arrive, and in what quantity? For physical goods this is the standard control, because it stops you paying for short or missing deliveries.

Some organisations add a fourth source, such as an inspection or quality check, but the logic is the same: every invoice line must be supported by independent evidence.

Matching rules and tolerances

The matching rules are where most of the value, and most of the difficulty, lives. A useful way to design them is to write them down as explicit rules before any tool is chosen.

Keys: how records find each other

Records rarely share a perfect identifier. Typical keys, in order of reliability:

1. PO number and line number on the invoice.
2. Supplier ID plus supplier item code.
3. Shipment or tracking number linking a delivery to a PO.
4. Fuzzy fallbacks: supplier name, amount and date range.

Decide what happens when the strongest key is missing. A common source of exceptions is suppliers leaving PO numbers off invoices, so the fallback rules matter.

Tolerances

Exact matching produces too many false exceptions. Tolerances define what counts as "close enough":

• Price tolerance: for example, accept a unit price difference up to a small percentage or fixed amount.
• Quantity tolerance: accept partial deliveries, or over-deliveries within an agreed margin.
• Rounding and currency: allow for rounding on VAT and conversion.
• Timing: an invoice may arrive before the goods receipt; it should wait, not fail.

Tolerances are a finance decision, not a technical one. Agree them with whoever owns payables and audit, and make sure they are visible and changeable without a code release.

Outcomes

Every record should end in one clear state: matched, matched within tolerance, waiting for evidence, or exception. "Waiting" is the state most manual processes forget, and the main source of next-morning surprises.

Exception triage and audit logs

Automation does not remove exceptions. It makes them visible sooner and easier to resolve.

A good triage view shows

• The invoice, PO and delivery evidence side by side.
• Which rule failed and by how much.
• Suggested causes: price change, partial shipment, missing PO number, duplicate invoice.
• Actions: approve with reason, request a credit note, contact supplier, escalate.
• Ageing, so overdue exceptions do not get lost.

The audit log should record

• Every automatic match, with the rule and tolerance applied.
• Every manual decision, who made it, when and why.
• Every change to the rules themselves.

If you work in a regulated area, this log is often the part auditors care about most. Build it in from the start rather than adding it later.

Buy options

There are three broad categories of tools that can reconcile invoices.

• ERP modules: most mid-market and enterprise ERPs include invoice verification and matching against POs and goods receipts. If all three documents already live in your ERP, this is usually the first thing to configure.
• AP automation platforms: dedicated accounts payable tools that capture invoices (often with OCR or document AI), route approvals, run matching and handle payment. They are strongest when your process looks like most companies' processes.
• Reconciliation and close tools: broader finance tools aimed at bank, intercompany and balance sheet reconciliations, sometimes with configurable matching engines.

What you buy is a proven product, a vendor that maintains integrations with common systems, and usually a quicker start. What you accept is the vendor's data model, its integration list, subscription pricing that often grows with invoice volume or users, and a process that has to fit the tool.

When a custom build makes sense

Building pays off when the hard part is not the matching itself but getting the evidence together. Signs you are in that situation:

• Delivery evidence comes from outside your ERP: carrier tracking APIs, a warehouse system, supplier portals or emails.
• Your matching rules are industry-specific, such as lot numbers, expiry dates or compliance checks before goods can be released.
• You need the results inside your own dashboards and data, not in another vendor's interface.
• Off-the-shelf tools would need so much customisation that you would be building anyway, on someone else's platform.

A medical and home supplies distributor we worked with was in exactly this position. Their operations team cross-checked POs from the ERP against DHL and UPS shipping confirmations, then reconciled invoices in SAP, every morning. Healthcare compliance meant every mismatch had to be logged and resolved before goods could be cleared.

We built a Python automation suite that polls the ERP, the carrier tracking APIs and the SAP invoice endpoint every 30 minutes, auto-reconciles clean records and sends discrepancies to a triage dashboard, with a daily digest by email. It removed about 20 hours a week of manual reconciliation, moved discrepancy detection from next morning to near real time, and populated the compliance log automatically. The full story is in the case study.

If you are choosing between a visual workflow tool and code for a project like this, our comparison of n8n, Zapier and custom code covers the trade-offs.

Build vs buy decision criteria

Answer these questions honestly. Mostly "yes" points to buying; mostly "no" points to building or a hybrid.

1. Are the PO, receipt and invoice all in one system you already use?
2. Can your matching rules be expressed with standard fields and tolerances?
3. Does a vendor integrate natively with every system you need, today?
4. Is your invoice volume stable, so per-invoice or per-user pricing stays predictable?
5. Are you comfortable with your finance data being processed in the vendor's environment?
6. Can your process change to fit the tool, rather than the other way round?

Also compare total cost over three to five years, not just year one: subscription and implementation for a bought tool; build, hosting and maintenance for a custom one. Our guide to calculating automation ROI shows how to set this up.

A common hybrid is to keep invoice capture and payment in an AP tool or ERP, and build a custom matching layer that pulls in the external evidence the tool cannot see.

Frequently asked questions

What is the difference between 2-way and 3-way matching?

A 2-way match compares the invoice with the purchase order. A 3-way match also checks proof of delivery, such as a goods receipt or carrier confirmation, so you only pay for what actually arrived.

Can reconciliation be fully automated?

The clean majority of records can be, but exceptions will always exist: price changes, partial shipments, missing references. The goal is that people only see the records that genuinely need a decision, with all the evidence in one place.

How long does a custom reconciliation build take?

It depends on the number of systems and the quality of their APIs. The distributor project above took six weeks. Mapping the rules and exceptions before writing code is what keeps timelines predictable.

Do we need OCR for invoices?

Only if invoices arrive as PDFs or paper without structured data. If suppliers send e-invoices or your ERP already holds invoice data, you can match directly. Our article on intelligent document processing explains the capture side.

If your team spends its mornings cross-checking orders, deliveries and invoices, see how our business process automation service works. Book a call and we will map your reconciliation process together, or request a quote if you already have the requirements.