At a glance
- Reconciling a co-packer means comparing four records per production run: ordered, produced, received and paid.
- A four-column loop table shows where each record originates, how an agent matches it, and where ops or finance resolves a variance.
- An agent does the matching, grouping and drafting; every variance decision stays with named ops and finance staff.
- Start with one co-packer and one product family, and run the loop beside your current process before relying on it.
- Test your co-packer's real invoice and shipping documents first; format fit is an empirical question, not an assumption.
How do you reconcile co-packer invoices against production runs?
Co-packer invoice reconciliation means tying each invoice line to the purchase order that authorized the run, the co-packer's record of what it produced, and your warehouse's record of what arrived, then deciding what to pay. The unit of work is the production run, not the invoice.
Accounts payable teams will recognize the pattern as a three-way match across the purchase order, the receipt and the vendor bill. NetSuite's product page says: "NetSuite performs a three-way match to correlate data on these documents."[1] A co-packer relationship adds a fourth record, the co-packer's production report, which states the production yield: the quantity of finished product a run produced.
The steps below are the working sequence. Each compares records at the same item and unit, because a case, a pallet and a single unit are different quantities. A bill of lading is the carrier's shipment document listing what left the co-packer's dock.
- Anchor the run
Link each invoice line to a purchase order line and a run or lot reference. A line with no anchor goes straight to review.
- Normalize units
Convert cases, pallets and eaches to one unit per item, and keep the original quantity and unit beside the converted one.
- Compare ordered to produced
Check the run's produced quantity against the quantity ordered, and the co-packer's stated yield against the agreed run plan.
- Compare produced to received
Check the shipment document and warehouse receipt against what was produced. Keep received, accepted and held quantities separate.
- Compare billed to all three
Check invoiced quantity and rate against the purchase order, the produced quantity and the accepted receipt.
- Route the variance
Group variances by type, attach the evidence, and send each group to the ops or finance owner who decides it.
The ordered-paid-produced-received reconciliation loop
The table below is the loop in one place. Read each row as one record in the chain: where the data starts, how an agent matches it, and who resolves a gap that match exposes. The rows follow the order a run moves through the business.
| Record | Where it originates | How an agent matches it | Where ops or finance resolves a variance |
|---|---|---|---|
| Ordered | Purchase order and co-packing agreement in your ERP: item, quantity, unit, rate, planned run date. | Links each invoice line to a purchase order line by item, unit of measure and run or lot reference; flags lines with no match. | Finance confirms rate and terms; ops confirms whether a quantity change was agreed before the run. |
| Produced | Co-packer's batch log and production report, with lot numbers and reported yield. | Compares produced quantity to ordered and to billed at the same item and unit; flags any run billed above what was reported as produced. | Ops takes up yield shortfalls, scrap and rework with the co-packer and records the agreed outcome. |
| Received | Bill of lading (the carrier's shipment document) and your warehouse receipt, with quantities accepted and held. | Compares shipped to received, and received to accepted and held, without overwriting any of the three; flags missing or late receipts. | Warehouse and ops resolve count differences, damage and quality holds, and release held goods with evidence. |
| Paid | Co-packer invoice and your AP payment record, including credits and earlier payments for the same run. | Compares invoice to purchase order, produced and accepted quantities; checks duplicates and prior payments; drafts a short-pay or credit request. | Finance approves payment, short-pay or a credit memo request, and records the reason against the run. |
We recommend one design rule for all four rows: an agent adds a comparison next to each record and never edits the record itself. Keep expected, received, accepted and held quantities as separate fields so a later reviewer can see each one.
| Record | Quantity | Source document | What the agent flags |
|---|---|---|---|
| Ordered | 1,200 cases | Purchase order line | Baseline for the run |
| Produced | 1,180 cases | Co-packer production report | 20 cases below ordered; an ops question about yield |
| Received | 1,150 cases accepted, 30 held | Warehouse receipt after the bill of lading | Held cases are a state, not a shortage; ops confirms the inspection outcome |
| Invoiced | 1,200 cases | Co-packer invoice | 20 cases billed above produced; finance asks for a credit or a reason |
In this invented run the invoice matches the order but not the production report, so the agent flags the 20-case gap for finance and the 30 held cases for ops. Staff decide both: the held cases may be released, and the gap may be an agreed overrun.
What causes the ordered-paid-produced-received gap?
The gap comes from four records being created by different parties, at different times, in different units, so each stage can produce a billing discrepancy. The table below is a working checklist of variance types to look for.
| Variance | First thing to check | What the agent does | Who decides |
|---|---|---|---|
| Billed above produced | Production report revision, agreed overrun or minimum charge | Flags the run and drafts a question to the co-packer | Finance, with ops input on the run |
| Produced above received | Shipment in transit, short count, damage, quality hold | Compares shipment and receipt dates; keeps received, accepted and held apart | Warehouse and ops |
| Rate differs from purchase order | Amended agreement or price change not yet in the ERP | Shows invoice rate beside purchase order rate | Finance |
| Unit or pack mismatch | Cases versus units, pallet conversions | Applies the approved conversion and keeps both original quantities | Ops confirms the conversion |
| No order or duplicate invoice | Run started on a verbal request, or invoice resubmitted | Holds the invoice and links any earlier payment | Finance |
Microsoft's invoice matching documentation describes the receipt side of this check: "If the invoice quantity differs from the matched product receipt quantity, a quantity matching error exists."[2] We recommend treating a revised invoice or production report as a new version beside the original, not a replacement.
What does an agent automate in this reconciliation?
An agent automates the preparation work: reading invoices, shipping documents and production reports, extracting quantities, units and references, matching them to ERP records, and grouping the exceptions. It does not approve payment or settle a dispute with the co-packer.
- Reading invoice, bill of lading and production report PDFs or emails into structured fields, with a link back to the page each value came from.
- Matching lines across the four records by item, unit and run or lot reference, and applying your tolerance rules.
- Drafting the variance summary and a question to the co-packer, for a person to edit and send.
- Keeping the evidence trail: which records were compared, which rule fired, who decided, and when.
Rules-based matching already exists in ERP tools such as NetSuite. Its page says "Incoming vendor invoices are automatically matched against their corresponding POs and goods receipts", then analysed based on "predefined rules and tolerances".[1] Where your tools already do that well, keep them. An agent earns its place on the unstructured parts: co-packer documents that arrive as PDFs and emails and need reading before they can be matched.
The financial reconciliation automation page covers the general matching and exception pattern, and document review with human approval covers the extraction-and-approval pattern. This article applies both to one co-packer chain.
Who resolves a variance?
Your ops and finance staff resolve every variance. The agent proposes a classification and the evidence; a named person accepts, changes or rejects it. We recommend assigning each variance type to one owner role before go-live, so no exception waits for someone to claim it.
- Finance: rate and terms, short-pays, credit memo requests, duplicate invoices, payment release.
- Ops or production planning: yield, scrap and rework, run changes, whether an overrun was agreed.
- Warehouse or receiving: count differences, damage, quality holds and release of held goods.
- Controller: tolerance rules, write-off decisions, and the sign-off on any rule change.
We recommend that an agent never turns a hold into a short-pay on its own, because a hold means goods await inspection, not that the supplier shipped fewer. Microsoft's documentation lists a related step: "View and approve quantity differences between the invoiced quantity on the invoice and the received quantity on the product receipt."[2] When held goods are later released, append the release evidence to the record instead of rewriting the earlier inspection state.
Does this work with our existing co-packer's invoicing format?
Whether it works is settled by a trial on your co-packer's real invoices, shipping documents and production reports, not by an assumption about format. Run that trial before you commit to a build.
We recommend collecting these fields from each sample document: the supplier document reference, product code, quantity, unit and document revision. Then check whether each one can be read and matched. A missing unit or revision becomes a data request to the co-packer, and the extraction results on your sample show what a build would need to handle.
- Collect a sample of recent invoices, bills of lading and production reports from the co-packer, including a revised one and a short-ship.
- Map each document's fields to the four records, and note where a unit, lot reference or run date is missing.
- Run the extraction on the sample and have a staff member check every extracted value against the page.
Where to start: a first scoped workflow
Start with one co-packer and one product family where purchase orders, receipts and invoices are already in the ERP. That keeps the first loop small enough to check by hand, and it surfaces your real variance types before you write tolerance rules.
Run the loop in parallel with your current process for at least one full billing cycle. Compare what the agent flagged with what your team found, and adjust tolerances only with the controller's sign-off. When you are ready to scope the build, AI agent implementation describes how a workflow like this is defined and handed over.
When this doesn't apply
- Volume is low enough that a controller already ties out every run by hand without a backlog.
- Your ERP's three-way match already covers the invoices and the co-packer sends structured data; use the tool you have.
- The issue is a contract disagreement over charges; that is a conversation between finance, ops and the co-packer, not a matching problem.
Frequently asked questions
How do you reconcile co-packer invoices against production runs?
Link each invoice line to the purchase order and a run or lot reference. Then compare ordered, produced, received and invoiced quantities at the same item and unit. Group the differences by type and send each to the ops or finance owner who decides it, with the evidence attached.
What causes the ordered-paid-produced-received gap?
Four records are created by different parties at different times and in different units. Variance types to check include billed above produced, produced above received, rate differences from the purchase order, unit mismatches, and invoices with no order or a duplicate.
What does an agent automate in this reconciliation?
It reads invoices, shipping documents and production reports, extracts quantities, units and references, matches them across the four records, applies your tolerance rules, and drafts the variance summary. It does not approve payment, release held goods or settle a dispute with the co-packer; staff do.
Who resolves a variance?
Ops and finance staff resolve every variance. Finance owns rates, short-pays and credit requests. Ops owns yield, scrap and run changes. Warehouse staff own counts, damage and holds. The agent proposes a classification with evidence, and a named person accepts, changes or rejects it.
Does this work with our existing co-packer's invoicing format?
Test it on real documents before committing. Collect recent invoices, bills of lading and production reports, including a revised one and a short-ship, map their fields to the four records, and have staff check every extracted value. Missing units or lot references become data requests to the co-packer.
Related reading
- Financial reconciliation automation covers the matching-and-exception pattern this loop sits inside.
- Document review with human approval covers reading co-packer documents with a person approving the result.
- AI agent implementation describes how a workflow like this is scoped and handed over.
- Reconciliation match rules and exceptions covers tolerance-setting and exception routing in general.
More in Finance operations
Deal Jacket and Title/Registration Automation for Multi-Rooftop Dealer Groups
Deal jacket and title/registration automation for multi-rooftop dealer groups: a completeness checklist table, audit-gap handling and cross-store standards.
Auto DealershipsFranchise Brand-Standards Audit Documentation: Automating the Paper Trail Behind the Inspection
Franchise brand-standards audit documentation: how an agent turns photos, PDFs, forms and emailed fixes into one packet per location, ready when asked.
Multi-Unit Franchise OperatorsGroup and Folio Billing Audit: Catching the Leak Types a Normal Error Check Misses
A group and folio billing audit for hotel management companies: a leak-type table of rate code mismatches, missing closes, adjustments, orphaned charges.
Hotel Management Companies