Three-Way Invoice Matching for Freight Forwarders

Three way invoice matching for freight forwarders compares the carrier or supplier invoice against a booking baseline (a quote or accrual line) and shipment evidence such as a bill of lading, air waybill, or proof of delivery, before payment is released. Unlike manufacturing's purchase-order to goods-receipt to invoice routine, forwarders have no PO and no goods receipt: the baseline is a multi-charge quote with surcharges and accessorials, and the "received quantity" is a shipment event recorded in a TMS or forwarder operating system, not a stock movement against a SKU line.

That structural difference forces a structural design choice. A single tolerance band across every charge line — the default a manufacturing AP team imports into freight without thinking about it — is the wrong design here. Base rates need a tight tolerance, surcharges need a wider one, and quantity or weight mismatches need bands keyed to the mode and the carrier's own rounding rule. The rest of this article works through what that design looks like in practice: the document trio that actually exists in forwarding, why the manufacturing routine doesn't transfer, the failure modes that show up at scale, how to set tolerances and route exceptions, and the reference-integrity prerequisite that decides whether matching is even possible on a given carrier's invoices.

Most of the explainers that rank for "three-way matching" — the NetSuite, Stampli, Ramp, BILL pages a finance team encounters first — assume manufacturing AP. They describe the PO-to-goods-receipt-to-invoice loop and stop there. None of that maps cleanly onto a forwarder's invoice flow, which is why importing those rules into a freight environment produces the symptoms you may already be seeing: invoices over-flagging on legitimate surcharge variance, invoices passing through with overcharges buried in accessorial lines, and an AP team spending more time clearing exceptions than the matching framework was supposed to save.

---

The document trio that actually exists in forwarding

The three documents in a freight-forwarder match are the carrier or supplier invoice, the booking or quote (or its accrual line) that established the expected price, and the shipment evidence proving the move actually happened the way the carrier is billing for. Each one lives in a different system, carries a different reference-identifier set, and answers a different question. Matching is the discipline of joining them on the right keys and reconciling what the invoice charges against what the booking promised and what the shipment actually consumed.

The carrier or supplier invoice. This is the document being validated. It arrives as a PDF, a scanned image, a vendor-portal export, or — for the larger carriers — an EDI feed. It carries the charges (base rate, surcharges, accessorials, taxes), the reference identifiers the carrier chose to print on it (a carrier-internal reference, an MAWB or HAWB for air, an MBL or HBL plus container number for ocean, a consignment number for road, a parcel tracking ID for parcel), and a billing period or shipment date. The reference set on the invoice is the only thing that lets you join it back to the other two documents — so what the carrier prints, and what they don't, controls how much of the matching can be automated. This is what makes the carrier invoice the harder leg of the trio to integrate: the matching baseline depends on identifiers that the carrier, not the forwarder, decides to print, and getting those reference fields right at carrier onboarding pays back across every invoice that follows.

The booking, quote, or accrual baseline. This is the expected-price side of the match. It lives in the TMS or freight forwarding system where the shipment was booked, and it's made up of the contracted base rate (or the spot quote, depending on how the lane was sold), the contracted surcharges that should apply, the expected accessorials, and the FX rate that was quoted. For some forwarders this baseline lives as a formal quote document; for others it's an accrual line generated against the booking; for many it's both, with a hand-off between the operations team that booked the move and the finance team that accrued for it. Whichever shape it takes in your system, this is the carrier invoice matching baseline the invoice should be reconciling against — not the previous month's invoice, not a market average, and not the carrier's published tariff.

The shipment evidence. This is the operational proof that the move happened. For ocean it's the bill of lading and the container's gate-in/gate-out events. For air it's the air waybill, and increasingly the carrier's milestone events fed back through cargo community systems. For road it's the proof of delivery and any pallet-level scan data. For parcel it's the carrier's tracking record. For rail it's the waybill and the loading manifest. The shipment evidence carries the operational reference identifiers — container number, declared weight, volume, route, milestone dates — that the invoice's per-container, per-shipment, or per-weight charges should reconcile against. Matching freight invoice against bill of lading data is the recognizable shape of this leg in ocean, but every mode has its operational-evidence equivalent, and the matching framework is the same once you know which identifier joins to what.

The mode dimension matters less than the trio framework itself. Air binds MAWB and HAWB to chargeable weight; ocean binds MBL or HBL and container number to TEU and declared cargo weight; road, parcel, and rail each have their own join keys and unit-of-measure conventions (consignment number with pallet count or LDM, tracking ID with dimensional weight, waybill with car or wagon counts). The vocabulary and the units shift, but the three-way match still binds the same three documents. Ocean has its own deeper packet discipline — prepaid versus collect, lane-specific surcharge stacks, the freight bill versus the shipping invoice distinction — covered in our ocean freight billing packet validation article for teams whose volume is mostly ocean and who need that mode-deep view. For the multimodal forwarder, ocean is one mode in the trio, not the trio itself.

---

Why the manufacturing PO–GR–invoice routine doesn't transfer

The reason a forwarder's matching framework keeps misbehaving when designed against manufacturing three-way matching with PO and goods receipt is that the manufacturing trio binds three documents whose existence and shape are stable. A purchase order is a formal agreement, signed off, version-controlled, amended only through a documented change order. A goods receipt is a physical event recorded against a specific SKU and quantity at a specific warehouse location. An invoice is the bill against the PO line. Each document is single-purpose, single-shape, and exists in a system of record that produced it. Forwarding has none of those three in equivalent form.

No purchase order. The closest analog is the booking, the quote, or the accrual line in the forwarder operating system. None of those is a PO in the manufacturing sense. Bookings change between the day they're placed and the day the move completes — re-routings, mode swaps, equipment changes, rolled containers, missed cut-offs. A PO doesn't change after issue without a formal amendment workflow; a booking changes constantly, and the changes are recorded operationally rather than re-issued as new contractual documents. The matching baseline in forwarding is a moving target that the matching logic has to accommodate, which means the rule design has to recognize legitimate operational changes as part of the booking record, not as deviations from a frozen baseline.

No goods receipt. A shipment event recorded in the TMS — a container gate-out, a vessel departure, a POD scan, a milestone update from a cargo community system — is the equivalent in operational terms, but it isn't a confirmation that a defined SKU quantity arrived in a warehouse stock location. It is operational proof that a transportation event happened. The "received quantity" against which the invoice is being validated is a chargeable weight, a container count, a TEU, a distance, or a service performed — not an inventory delta. Anyone trying to map a goods receipt straight onto a shipment event will keep finding that the reconciliation question is different: not "did we receive what we ordered" but "did the move that the carrier is billing for actually happen, and at the scale they're billing for it."

No single-line expected price. A PO line carries a single agreed unit price. A freight booking's expected price is a multi-line quote: base rate, fuel surcharge, BAF or CAF, peak-season surcharge, GRI, security fees (ISPS, ISF, AMS, ENS, depending on the lane), terminal handling, documentation fee, and any operationally triggered accessorials such as demurrage or detention. Manufacturing matches one PO line to one invoice line within a tolerance band. Freight matching reconciles a basket of charges against a basket of expected charges, plus the operational events that legitimately add charges to the basket after the booking was made. There is no single price to compare to a single line.

The consequence is concrete and shows up immediately when a manufacturing-style framework gets applied to freight. A team that sets a single tolerance band across all charge lines either over-flags every invoice — because surcharge lines fluctuate within legitimate operational ranges, and the band is tighter than the natural variance — or pays through invoices that should have been disputed, because a single permissive band hides a 30% overcharge in one surcharge line behind aggregate-total tolerance that the other lines satisfy. Both failure modes look the same from the AP team's perspective: the matching system isn't doing its job.

For shippers (rather than forwarders) the manufacturing routine still applies on the inbound goods side — the freight invoice is a separate, parallel matching problem on the transportation cost line, alongside the goods invoice running through PO matching. This distinction quietly confuses reorganizing finance teams that try to consolidate "all invoice matching" under one ruleset; freight cost matching needs its own framework, regardless of where the rest of AP sits. The shipper-side freight audit and payment process covers what that parallel discipline looks like for organizations that are predominantly the shipper rather than the forwarder.

---

Why freight invoice matching breaks down at scale

Matching one freight invoice manually is a clerical job — pull up the booking, pull up the BOL, check the charges, approve. Matching ten thousand a month against the same standard is a structural problem with five distinct failure modes, and any one of them is enough to collapse a workflow that worked at a hundred a month.

Inconsistent invoice formats. Carriers, NVOCCs, brokers, customs brokers, and overseas agents each have their own invoice layout. The same charge appears in different positions, under different labels, with different itemization granularity. One carrier breaks fuel surcharge into per-leg lines; another rolls it into a single shipment-level line; a third bundles it into the base rate and surfaces it only in the rate footnote. Manual matching teams build informal mental maps of "how this carrier bills," and those maps don't survive turnover, don't transfer when a new carrier is onboarded, and don't scale past the volume one analyst can hold in their head. By the time a forwarder is processing invoices from forty carriers across six modes, the mental-map approach has become institutional risk.

Surcharge and accessorial label drift. The same charge has different names across carriers and lanes. Bunker adjustment factor, BAF, fuel surcharge, FAF, fuel adjustment — the same economic line, four labels. Peak-season surcharge, PSS, seasonal adjustment — same charge, three labels. Security fee, ISPS, ISF, AMS, ENS — these are not all the same charge, but they share a category and the line names overlap enough that rule logic written against label strings fails when a carrier introduces a fifth name or rebrands an existing one. Terminal handling charge, THC, origin handling, destination handling, terminal service — same family, five labels. A matching engine that recognizes only the labels it's been taught will silently miscategorize anything new and either flag it as unrecognized or pass it through under the wrong tolerance band.

Currency and unit-of-measure normalization. Carrier invoices arrive in the carrier's billing currency, converted at the carrier's chosen FX date — sometimes the invoice date, sometimes the shipment date, sometimes the contracted billing-period date. The booking baseline sits in the forwarder's accrual currency at the booking-date FX. A "mismatch" between booking and invoice can be entirely explained by FX timing differences that don't represent any real overcharge. Weights arrive in pounds from one carrier and kilograms from another. Volumes in CBM, CFT, or revenue tons depending on the mode and the trade lane. Container quantities apply per-shipment for some surcharges (terminal handling per BL) and per-container for others (THC per TEU). Without a normalization layer that aligns currency, units, and per-unit basis before tolerance is checked, every comparison is unreliable and the exception queue fills with noise.

Legitimate operational exception versus true billing error. A re-routing during the move that shifted the lane and triggered a higher base rate is a legitimate variance, provided the operations team has the re-route on file. Demurrage that the consignee actually incurred because they were late on collection is a legitimate variance, provided the gate-in/gate-out timestamps confirm the dwell. A peak-season surcharge that fired between booking and billing within the carrier's published GRI dates is legitimate. Against those, a duplicated charge appearing on two invoices for the same shipment leg is a billing error. A surcharge applied at a unit rate that contradicts the contracted rate card is a billing error. A per-container surcharge billed against a shipment that didn't use that container count is a billing error. The matching layer has to distinguish the two — flagging both as "exception" and dumping them on an analyst defeats the framework, because the analyst then re-litigates the same operational-versus-billing-error judgment on every shipment.

Manual rekeying as a hidden tax. Most carrier invoices arrive as PDFs, scanned images, vendor-portal exports, or EDI fragments that cover only a subset of the data the matching layer needs. The matching workflow has two ways to deal with this: run only on the digitally clean subset (the EDI feeds from the major carriers) and skip the long tail, or burn AP analyst time keying the rest into the matching system by hand. The first option leaves a coverage gap that defeats the whole point of having a matching framework. The second option scales linearly with invoice volume in headcount terms and becomes the dominant cost in the AP function past a few hundred invoices a month.

What ties these failure modes together is upstream of the matching engine itself. Matching is only as good as the structured charge data feeding it: line-itemed, with surcharge categories normalized, units aligned, and the reference identifiers preserved on every line. Without that, even a sophisticated tolerance and exception design degrades to whatever subset of invoices arrives clean. This is where invoice extraction sits in the stack — as the upstream layer that turns unstructured carrier invoices into the line-itemed, reference-preserving data the matching workflow runs on. We build AI-powered freight invoice data extraction for exactly this constraint: it converts batches of carrier invoices in any of the formats they arrive in (PDF, scanned image, vendor-portal export, mixed multi-page files) into structured per-invoice or per-line-item output that preserves the booking, MAWB, MBL, container, and shipment references the matching layer joins on, with the surcharge labels and units captured as the carrier wrote them so the normalization layer downstream has something concrete to work with.

The deeper mechanics of how that extraction layer handles carrier invoices specifically — multi-invoice PDFs, scanned packets, mixed-format batches, label variation across carriers — are covered in automated freight invoice data extraction. The matching framework in the rest of this article assumes that upstream layer is in place, in some form, and that the matching engine is being fed structured charge data with reference integrity intact. If it isn't, every section that follows is a description of what the framework would do if it could see the data.

---

Designing tolerance rules: base rate, surcharges, and quantity

A single tolerance band across every charge line is the wrong design for freight, because the three categories on a freight invoice — base rate, surcharges and accessorials, quantity and weight — have fundamentally different volatility profiles and different operational legitimacy windows. Set a tight global tolerance and surcharge variance floods the exception queue. Set a permissive global tolerance and overcharges in surcharge lines pass through under aggregate-total cover. The fix is to design three separate bands, each tuned to the volatility of the charges it covers, so the freight invoice validation workflow flags only what genuinely needs review.

Base rate. Base rates come from a contracted lane rate, a spot quote, or (rarely, in a forwarding context) a published tariff. They should match the booking baseline within a tight band — typically cents per unit on a contracted lane, with anything beyond a 1–2% upper tolerance flagged for review. That 1–2% headroom covers FX rounding and minor rate-card timing where the carrier billed against a card that took effect mid-period; it does not cover unit-rate disagreement, which is almost always a wrong-rate-card application, a misapplied lane reference, or a carrier billing system that defaulted to a different contract. When the base rate moves outside that band, the answer is dispute, not a wider tolerance.

Surcharges and accessorials. Surcharges legitimately fluctuate between booking and billing. Bunker and fuel adjustments rebill on monthly or quarterly cycles tied to an index the carrier publishes. Peak-season surcharges fire on dates that may shift if the carrier reissues a guidance notice. Currency adjustment factors track FX and can drift several percent inside a normal billing month. A wider tolerance — typically 5–15% per surcharge line, often combined with an absolute-value floor below which any variance auto-passes (small-dollar surcharge differences aren't worth the AP cycle to clear) — fits this volatility better. The principle is that tighter tolerances on surcharges flood the AP team with exceptions that resolve to "pay" 80–90% of the time, which trains the team to wave through everything in the queue and erodes the matching discipline the framework was meant to create. The framework holds up better when the rules acknowledge upfront that surcharge-line variance is mostly legitimate, and the matching effort focuses on the variances large enough or persistent enough to justify a dispute. This is also the layer where carrier-specific overrides matter most: each carrier's surcharge rebill cadence is a known parameter, and the freight surcharge tolerance rules in your matching system should reflect it where the rule engine supports per-carrier overrides.

Quantity, weight, and volume. Mode-keyed bands. Air uses chargeable weight with rounding rules that produce small legitimate variances at the carrier-rule level — IATA defines a chargeable-weight rounding convention but individual carriers apply it with their own conventions, and a half-kilo difference is not a billing error. Ocean uses container counts (per-container surcharges should reconcile against the actual container manifest) plus declared cargo weights, which can differ from manifest weights when shipper-declared weight and verified gross mass diverge within the per-shipment range that the SOLAS framework allows. Road uses pallet counts or loading-meter (LDM) measurements; the LDM-versus-pallet convention varies by lane and by carrier. Parcel uses dimensional weight with each carrier's own dim divisor (DHL, FedEx, UPS, and regional carriers all publish different divisors, and they change). Tolerance bands here should be set per mode and, where the rule engine allows, per carrier's stated rounding rule — not as a single percentage spread across modes that don't share a measurement convention.

Tolerance asymmetry. The under-billed and over-billed sides of a tolerance band carry different financial risk. Under-billing — the carrier billed less than the booking baseline expected — should typically pay through without an exception, because the cost-control problem is overcharging, not undercharging, and the AP team's analyst time is better spent reviewing variances that move money out of the door. Over-billing should flag at the same percentage threshold you'd otherwise set symmetrically. A symmetric tolerance design treats under- and over-billing as equally worth investigating, which they aren't, and routes saved-money exceptions into the queue alongside paid-extra exceptions.

Tolerance evolution. Tolerances are not set once. They have to be reviewed after each carrier rate-card update, after each seasonal surcharge cycle change, and after any lane re-tender that changes the contracted rate basis. A tolerance design that has not been touched since it was first configured is silently miscalibrated against current rates and current surcharge cadences, and the symptom of that miscalibration is usually exception-queue volume drifting upward over months without anyone naming the cause. Build a periodic review into the matching process — quarterly is a defensible cadence for most forwarders — and treat it as part of the matching framework, not a maintenance task.

The granularity the rule engine supports decides how much of this design actually lands. Some matching tools, freight-audit modules, and TMS reconciliation features support per-lane and per-carrier tolerance overrides. Some don't, and force a coarser global rule with more downstream exception review. Knowing which side of that line your system sits on is part of the design — there's no point specifying a 7% tolerance on a specific carrier's BAF line if the engine only accepts a single global surcharge tolerance. In that case the realistic design is a coarser band paired with a more disciplined exception-routing layer that catches what the tolerance can't.

---

Exception taxonomy: pay, dispute, or hold pending evidence

Every exception that survives the tolerance check resolves to one of three outcomes: pay (the variance is legitimate and the operational evidence supports it), dispute (the variance is a carrier billing error and the contracted terms support a chargeback), or hold pending evidence (the matching system can't reach a conclusion yet because the reference data isn't complete). The work of an effective exception layer is making that routing deterministic — driven by criteria that are written down and consistently applied — rather than leaving each variance to the next available analyst's judgment.

Pay — legitimate operational variance, properly documented. The reroute that shifted the lane from one ocean alliance's service to another's mid-move and triggered a higher base rate, with the operations team's reroute notice on file. The demurrage that the consignee actually incurred because they were late on collection, with gate-in and gate-out timestamps confirming the dwell against the carrier's free-time terms. The peak-season surcharge that fired between booking and billing, within the carrier's published GRI window. The redelivery accessorial billed against a parcel where the first delivery attempt failed and the carrier's tracking record proves it. The criterion in every case is the same: there is operational evidence on file that explains the variance against the booking baseline, and the variance is consistent with what that evidence implies. Pay-routed exceptions should be logged with the supporting evidence so the next time a similar pattern appears the routing rule fires automatically.

Dispute — true carrier billing error. A duplicated charge appearing on two different invoices for the same shipment leg. A surcharge applied at a unit rate that contradicts the contracted rate card (a bunker line billed at the carrier's published index value rather than the contracted indexed rate). A per-container surcharge billed against a shipment whose container count was lower than what the invoice charges. An accessorial billed without any operational event on file that would have triggered it (a detention charge with no gate-in event, an examination fee with no customs hold record). A unit-rate misapplication where a carrier's billing system applied the per-kilogram rate to a per-pound declared weight, or the per-leg rate to a per-shipment basis. The criterion: the variance is unexplained by operational evidence and contradicts the contracted or quoted terms. Dispute-routed exceptions need a clear chargeback workflow, a tracked dispute reference with the carrier, and an aging clock — open disputes that sit untouched past the carrier's dispute window become unrecoverable, which is its own form of cost leakage.

Hold pending evidence — matching cannot conclude. Shipment evidence missing or not yet received from the carrier or partner, where the invoice has arrived ahead of the operational data feed. Reference identifier on the invoice doesn't match any open booking — possibly a reference-integrity failure, possibly a rebill against a closed booking, possibly a carrier billing for a shipment the forwarder didn't book. POD missing on a leg where the invoice charges proof-of-delivery completion. The hold queue is structurally different from the dispute queue: it is waiting on data that should arrive, not waiting on a counterparty to agree. Set a maximum hold age — five to ten business days for most patterns, longer for evidence that depends on a partner agent in a slow geography — after which the held item escalates to either a manual reconciliation or a formal request to the carrier for the missing reference data. Without that escalation rule, the hold queue silently absorbs invoices that never resolve, and the forwarder's accounts payable runs months behind on a slow-decaying tail.

The judgment trap. When AP analysts handle every exception case-by-case without a shared criteria framework, they routinely re-litigate the same situations across different shipments. Two analysts produce different decisions on functionally identical exceptions because each is running their own internal model. The taxonomy works only when each routing decision is logged with the criterion that produced it — pay because of reroute evidence, dispute because of unit-rate contradiction, hold because of missing POD. Over time the logged decisions become the rule set: similar future exceptions route automatically because the team has already decided how this specific pattern is handled. Without the logging discipline the team is doing matching from scratch every month and can't give a defensible answer to the auditor's question of how exceptions are being handled.

Most forwarders run this routing inside their TMS, freight forwarding system, or ERP — CargoWise, Magaya, Logitude, Cargobase, Descartes, and the ERP-side equivalents in Microsoft Dynamics, Oracle, and SAP all have varying degrees of native exception-routing support. Tolerance and routing design has to fit the rule expressivity of the system it lives in: a system that supports per-carrier overrides and conditional routing rules can carry a more nuanced taxonomy than one that only supports a single global threshold. The design also has to survive system upgrades and migrations, which means writing the criteria down independently of the system implementation rather than letting them live as configurations that disappear when the platform changes. For teams operating inside CargoWise specifically, the practical mechanics of configuring this routing — where the freight forwarder AP exception handling rules live in the platform, how to wire them to the matching engine, and which workflows the system supports out of the box — are covered in our CargoWise AP invoice automation workflows article.

---

Reference integrity: the foundation that makes matching possible

Everything in the document trio, the tolerance design, and the exception taxonomy depends on one upstream condition: the carrier invoice has to carry the reference identifiers that tie it back to the booking baseline and to the shipment evidence. Booking number, MAWB or HAWB for air, MBL or HBL plus container number for ocean, consignment number for road, parcel tracking ID, shipment ID — without these on the invoice itself, the matching engine has no join key, and the framework collapses into a manual reconciliation queue regardless of how well the rules are designed.

Reference-integrity failure shows up in recognizable patterns. An invoice that carries only the carrier's internal reference number and no booking number — common from smaller agents and from carriers whose billing systems weren't built to surface customer-side identifiers. A consolidated invoice covering twenty shipments with no per-shipment breakdown, where the totals are correct in aggregate but no individual line can be tied to an individual booking. An accessorial charge billed against the wrong leg's reference because the carrier's billing system applied the reference at the consol level rather than at the leg level. A re-billed invoice that lost its original cross-reference, with the carrier treating it as a fresh document rather than a credit-and-rebill against a known prior. Every one of these forces the affected lines into the hold-pending-evidence queue, and the resolution work is manual reconciliation against whatever fragments of the carrier's data the AP team can piece together from the portal or by email.

The expectation that commercial invoices carry itemized charges and trackable identifiers isn't a niche logistics preference imposed on carriers by demanding forwarders. It's codified in customs regulation for imported merchandise: 19 CFR § 141.86 commercial invoice contents requirements requires every commercial invoice of imported merchandise to itemize all charges by name and amount — including freight, insurance, commission, and packing — and to identify the merchandise with marks, numbers, and symbols sufficient to be tracked across documents. The regulation exists because customs needs to verify charges and identify goods across the documentary chain; the same itemization and identifiability that customs requires is the foundation that operational matching runs on. A carrier whose invoice doesn't meet the regulatory bar for documentary identifiability also doesn't give a forwarder's matching engine the join keys it needs. Treat the regulatory baseline as the floor, not the ceiling: the matching framework needs the same identifiers customs needs, plus whatever additional booking, shipment, and contract references the forwarder's own systems use to reconcile.

The operational consequence is upstream of the matching engine. The most effective place to enforce reference integrity is at carrier onboarding, in the contract and the invoice template specification: the booking number must appear on every invoice line; the MAWB, MBL, or container number must appear at the appropriate granularity; consolidated invoices must include a per-shipment breakdown with the forwarder's reference set carried through. Building this into the carrier relationship at the start is much cheaper than building rule logic that tries to repair broken references after the invoice has arrived. When a new carrier's invoice template is missing fields the matching engine needs, the right response is to fix the template — not to engineer downstream workarounds that absorb the integrity gap.

Reference integrity is also what makes invoice extraction useful, and it's a hard limit on what extraction can produce. Extraction can only preserve what the invoice contains. If the carrier never put the booking number on the invoice, no extraction layer — however sophisticated — can recover it. The same constraint applies to per-line-item reference granularity, FX rate disclosure, and any other field the carrier chose not to print. The remedy in all of these cases is upstream of both extraction and matching: in the carrier-onboarding contract, in the invoice template specification, and in the periodic review of which carriers' invoices the matching engine is actually able to validate without manual reconciliation. That review, more than any tolerance tuning or exception-rule refinement, is what determines whether the matching framework is doing the job it was designed for.