Agentic Consignment Inventory Reconciliation: Matching What's On the Floor to What Actually Gets Invoiced
written by Cooter:Labs
published on September 24, 2026
Introduction
Consignment inventory breaks the usual rule that stock on your floor is stock on your books. A supplier ships product into a customer's warehouse, or a manufacturer places components at a contract assembler's site, and the goods sit there physically received but not yet owned by whoever is holding them — ownership, and the obligation to pay, only transfers at the moment of actual consumption: a unit gets pulled onto the line, a case gets scanned out to a patient floor, a part gets installed into a build. Between the physical receipt and that consumption event, the ERP has to track two different truths about the same pallet: it's in this location, and it belongs to someone else, right up until a specific transaction flips both facts at once. Most of the reconciliation problems in consignment programs come from that gap being tracked by two separate systems — a warehouse or point-of-use system that knows what physically moved, and a billing or accounts-payable process that runs off usage reports someone compiled by hand — and the two rarely agree on the same number by the time an invoice is due.
A consignment agreement usually specifies exact terms — what triggers consumption, how often usage gets reported, what happens to unconsumed stock at a periodic true-up or contract end — but applying those terms consistently means matching a physical event (a pull, a scan, a pick) recorded in a warehouse or MES system to a billing rule that lives somewhere else, for every single unit, continuously. When that matching is done by exporting a usage report once a week and reconciling it by hand against what's on the shelf, the two clocks drift: units get consumed but not reported, reported but not actually consumed, or reported twice because two different systems both logged the same pull.
When consigned stock arrives, the agent records it in the ERP as received-not-owned: it exists at a location and shows up in on-hand counts for planning purposes, but it's flagged against the specific consignment agreement and supplier (or customer, for consignment placed outward) that still holds title. This matters because a generic goods-receipt process that only tracks location will show the stock as available inventory the moment it's put away, which is operationally correct — it can be picked and used — but financially wrong, since no liability or payable should exist yet. The agent keeps the ownership flag attached to the specific lot or serial range from receipt through consumption, not just to the SKU in aggregate, so a partial pull from a larger consigned lot doesn't lose track of which units are still unconsumed.
Consumption isn't always a simple pick-and-issue transaction. Some agreements trigger on a warehouse pick to a work order, others on point-of-use scanning at the shop floor or a hospital supply cabinet, and others on a downstream sale of the finished good that incorporated the consigned part. The agent reads the specific trigger written into that agreement and watches for it in the system that actually generates it — the WMS pick transaction, the MES component-issue event, or the sales order for the finished item — rather than assuming every consignment line converts the same way. A component consumed on the shop floor gets flagged the moment the issue transaction posts; a part whose agreement triggers on the customer's resale doesn't get flagged until that resale transaction exists, even though it physically left the shelf earlier.
Most consignment agreements call for the holding party to periodically report consumption back to the owning party, and that report is what actually drives billing — but a report compiled from a spreadsheet or a separate portal can disagree with what the ERP's own transaction stream shows happened. The agent compares the two independently: for every consumption event it recorded internally, does the supplier's or customer's usage report show the matching quantity for the same period, and for everything on their report, does the agent's own transaction history support it. A unit reported as consumed that never shows a corresponding pick or issue transaction gets flagged as a possible over-report; a unit the agent's own records show consumed but that's missing from the report gets flagged as unbilled or under-collected exposure.
Consignment agreements typically carry their own clock separate from ordinary inventory aging — a maximum time stock can sit unconsumed before it must be returned, repurchased outright, or renegotiated, and sometimes a minimum consumption commitment that triggers a penalty if it isn't met. The agent tracks each consigned lot against its agreement's specific aging and commitment terms rather than the company's generic slow-moving-inventory thresholds, since consigned stock that would be unremarkable under normal aging rules can already be in breach of its consignment terms. It flags lots approaching a return deadline, and separately flags a consumption shortfall against a minimum-take commitment before the counterparty's own tracking catches it and raises it as a dispute.
When the agent's internal transaction record and the counterparty's usage report agree, the reconciliation closes itself and the resulting invoice or self-billing entry goes through without anyone touching it. When they disagree, the agent doesn't guess which side is right — it surfaces the specific discrepancy (which lot, which period, which direction the mismatch runs, and the dollar exposure) to whoever manages that supplier or customer relationship, since resolving it usually means a conversation about whose system missed a transaction, not a records lookup the agent can finish on its own.
Looking Ahead: Challenges and Innovations
The mechanism is only as reliable as point-of-use capture
This entire reconciliation depends on the consumption event actually being captured electronically at the moment it happens — a barcode scan, an MES issue transaction, a cabinet pull. Where consumption still happens informally (someone grabs a part off a consignment shelf without scanning it, intending to log it later), there's no transaction for the agent to match against, and the gap between physical and recorded consumption reopens exactly where the mechanism is supposed to close it. It's strongest in environments with disciplined scan-at-point-of-use discipline already in place, and it can't manufacture that discipline where it doesn't exist.
Disputed consumption triggers are a contract interpretation question
Some agreements have ambiguous or loosely written consumption triggers — does a part count as consumed when it's issued to a work order, or only when that work order actually completes and the part is confirmed installed versus scrapped in process. The agent applies whatever trigger definition it's configured with consistently, but it can't resolve a genuine disagreement between the two parties about what the contract language actually means; that stays a conversation between whoever negotiated the agreement and their counterpart, informed by the transaction history the agent surfaces rather than settled by it.
Return and buyback logistics still need a human decision
When aged or excess consigned stock needs to go back to the owning party, or gets bought out instead, deciding which path makes sense — factoring in shipping cost, whether the stock is still sellable elsewhere, and the state of the broader relationship — is a judgment call, not a data lookup. The agent's job is to surface that the stock has aged past terms and quantify what's at stake; it doesn't decide whether the answer is return, buyout, or a renegotiated deadline.
The metaverse
Consignment programs have historically been tracked at the edges of the ERP, often in spreadsheets bolted onto whatever the warehouse or point-of-use system already did, because the ownership-flip-on-consumption logic doesn't map cleanly onto a standard goods-receipt-to-invoice flow. As more point-of-use systems — shop-floor MES, hospital supply cabinets, retail point-of-sale — expose real-time transaction data rather than end-of-day batch exports, the more useful direction is treating consignment consumption as a live signal that reconciles continuously against the counterparty's own records, rather than a monthly spreadsheet exercise that surfaces disagreements only after both sides have already closed their books on the period.
Conclusion
Consignment inventory asks an ERP to track two facts about the same stock that normally move together — physical location and financial ownership — and let them diverge until a specific consumption event brings them back in sync. Doing that reliably means capturing the actual consumption trigger the agreement specifies, matching it independently against whatever usage report the counterparty produces, and watching the agreement's own aging and commitment terms rather than generic inventory rules. None of that replaces the judgment call in a genuine contract dispute or a return-versus-buyout decision — it means those conversations start from a reconciled, agreed-upon transaction history instead of two spreadsheets that already disagree before anyone's looked at them.
Share this post:
Curious what this means for your business?
Get a personalized ROI estimate, or book a free discovery workshop with our team.