An order for 100 units that ships in one box is a two-document chain: an order and an invoice. The same order shipping in three boxes over five weeks, with one line substituted and five units returned, is a chain of eleven documents whose quantities have to reconcile against a customer’s accounts payable system you have no visibility into. The second case is normal in wholesale and distribution. Most systems are designed for the first.
This post covers the document chain: what the parent and child relationships have to be, how quantities are matched at line level, how partial payments attach, and the specific failure that occurs when a chain-aware seller meets a single-document assumption on either side.
One order, many shipments, many invoices
The structural rule is short. The sales order is a parent. Shipments and invoices are children of it, and quantities are tracked per line, not per document.
That means an order line carries four quantities at all times:
- Ordered. What the customer committed to.
- Reserved. Committed stock not yet dispatched, described in inventory reservations.
- Shipped. The sum of quantities across all shipments referencing this line.
- Invoiced. The sum of quantities across all invoice lines referencing this line.
Open quantity is ordered minus shipped minus cancelled. When it reaches zero, the line is complete. When every line is complete, the order is. No order-level status flag can substitute for this, because an order with three lines can be fully shipped on two of them and half-shipped on the third, and “partially shipped” tells nobody which.
The invoiced quantity is deliberately tracked separately from shipped, even under the rule that invoices are raised from shipments. Shipped and invoiced should always be equal, and the way you find out that they are not is by storing both and comparing them.
The chain, traced through one order line
An order line for 100 units at 50.00, shipped three times, with a partial return.
| Step | Document | Quantity | Line value | Open on the order line |
|---|---|---|---|---|
| 1 | Sales order line | 100 ordered | 5,000.00 | 100 |
| 2 | Shipment 1 | 40 | 60 | |
| 3 | Invoice 1, from shipment 1 | 40 | 2,000.00 | 60 |
| 4 | Shipment 2 | 35 | 25 | |
| 5 | Invoice 2, from shipment 2 | 35 | 1,750.00 | 25 |
| 6 | Payment, allocated | covers invoice 1 in full, 500.00 against invoice 2 | 2,500.00 | 25 |
| 7 | Return, 5 units from shipment 2 | 5 | 25 | |
| 8 | Credit note against invoice 2 | 5 | 250.00 | 25 |
| 9 | Shipment 3 | 25 | 0 | |
| 10 | Invoice 3, from shipment 3 | 25 | 1,250.00 | 0 |
Every row references its parent. The credit note in step 8 attaches to invoice 2 specifically, because that is the document that billed the returned units, and that is the document whose tax treatment and exchange rate the credit has to mirror. The payment in step 6 records two allocations rather than a single balance reduction, so the open receivable is 1,250.00 against invoice 2 and not an undifferentiated amount against the customer.
Total invoiced is 5,000.00, total credited is 250.00, total shipped is 100 with 5 returned. Every one of those numbers is derivable from the chain rather than maintained as a separate running total, which is the same reason a ledger derives statements from posted entries instead of from kept-up balances, as described in double-entry accounting for founders.
The failure: a three-way match against a single-document assumption
Now the concrete failure, and it happens on the buyer’s side where you cannot see it.
Your customer’s accounts payable process performs a three-way match: their purchase order, their goods receipt note, and your invoice must agree before payment is released. Their purchase order is for 100 units. Their system was configured on the assumption that one purchase order yields one invoice, so it matches invoice totals against purchase order totals.
You send invoice 1 for 40 units, 2,000.00. Their system compares 2,000.00 against a purchase order of 5,000.00, finds a variance of 3,000.00, and routes the invoice to exception handling. A person there has to decide whether you underbilled, whether the order was amended, or whether something is wrong. Invoices 2 and 3 do the same thing. Your credit note, which their system cannot attach to an invoice it has not yet approved, goes to a separate queue.
You are not paid on any of the three invoices at their due dates. Your receivables aging shows three overdue documents. Your collections process chases a customer who is not refusing to pay and is not in dispute. The root cause is a configuration assumption in a system belonging to a different company, and the only thing that resolves it is a phone call and a manual match.
The seller-side lesson is not that partial invoicing is wrong. It is that the chain must be explicit in the document itself: every invoice states the order it belongs to, the shipment it bills, the line-level quantities and the customer’s own purchase order reference. A line-level match succeeds against 40, 35 and 25 where a total-level match fails, and the reference data is what lets the buyer’s system do the line-level version.
What breaks when the chain is flattened
| Capability | Chain-aware system | Single-document assumption |
|---|---|---|
| Second delivery of an order | Second shipment, second invoice | Manual invoice with no link to the order |
| Backorder tracking | Open quantity per line | A note in a comments field |
| Return from a specific delivery | Credit note against the billing invoice | Credit note against the customer balance |
| Partial payment | Allocation to named invoices and amounts | Oldest-first cash application, unrecorded |
| “Why is this invoice unpaid?” | Traceable to a shipment and a receipt | Answerable only by asking the customer |
| Revenue timing | Per shipment, at transfer | At whatever document was raised first |
The flattened column is not missing features. It is missing a relationship, and every one of those rows is the same missing relationship showing up somewhere different.
Where partial invoicing should be refused
Two boundaries are worth naming plainly.
Do not invoice more than was shipped. An invoice quantity greater than the cumulative shipped quantity for that line is not a partial invoice, it is an error, and it should be rejected rather than corrected later. The receiving side of the same rule applies to purchase orders: receiving more than was ordered is refused in Oneop with an over-receipt error rather than clamped silently to the ordered quantity, because a silent clamp loses the fact that the supplier sent extra.
Do not split an invoice for cash-flow reasons. Invoicing half of an unshipped order to bring revenue forward puts a document into your customer’s accounts payable that their goods receipt will never match. If early payment is the goal, the instrument is a deposit request, which does not assert that goods were delivered.
How Oneop handles the chain
Shipping a sales order in Oneop’s inventory module raises the invoice for that shipment as part of the same transaction that writes the shipment, decrements stock, posts cost of goods sold and advances the order status. An order that ships three times produces three shipments and three invoices, each billing the quantity its own shipment contained, because the invoice is generated by the dispatch event rather than assembled afterwards from an order total.
Each of those invoices posts to the ledger the same way any other does: receivables debited, revenue and tax credited, both sides named in one posting, with the finance module refusing an unbalanced entry before any row is written. Voiding one of the three reverses its ledger entry and releases the stock it reserved in the same action, which is the property that lets you undo the middle document of a chain without the other two becoming wrong.
Returns and lot tracking are available from the Pro plan upward, listed on pricing alongside the other inventory entitlements. The invariant that invoices bill shipped quantities is not a plan feature, and the reasoning behind it is set out in invoicing from what shipped rather than what was ordered.