There is one line of configuration in most business systems that decides how much time your finance team spends issuing credit notes. It is the question of which document raises the invoice: the sales order, or the shipment. Choosing the sales order looks faster. It is the reason a single order line ends up spread across an invoice, a credit note, a second invoice and an email thread nobody wants to read.
The argument here is an invariant, not a preference. An order records intent. A shipment records fact. Only fact is billable.
An order is a promise, and promises change
A sales order is a statement about the future: these items, this quantity, this price, at some point. Everything on it is subject to revision until the goods physically leave.
Between confirmation and dispatch, the normal operational events are all quantity-changing:
- Short-ship. Ten were ordered, seven were picked, because the count was wrong or the last three were damaged.
- Backorder. Part of the line is not in stock and will ship next week from a purchase order that has not arrived.
- Substitution. The customer accepted a different SKU, at a different price.
- Cancellation. The customer changed their mind before picking started.
- Split by warehouse. Six ship from one location today, four from another tomorrow.
None of these is exceptional. In any business holding physical stock, they are the week. Invoicing at order time means every one of them arrives as a correction to a document that has already been sent, filed and, in many cases, entered into the customer’s accounts payable system.
The credit-note churn, traced through one order
Here is the concrete failure case. A customer orders 10 units at 50.00. The system invoices at confirmation.
| Event | Document created | State of the customer’s AP |
|---|---|---|
| Order confirmed, 10 units | Invoice A, 500.00 | Expects 10 units, owes 500.00 |
| 7 units picked and shipped | none | Received 7, holding an invoice for 10 |
| Customer disputes | none | Payment held pending resolution |
| Finance corrects | Credit note, 150.00 | Two documents, net 350.00 |
| Backorder of 3 ships later | Invoice B, 150.00 | Three documents for one purchase order |
One order line has become three finance documents and a support conversation. The receivables aging report is wrong for the whole dispute window, because 500.00 sat in the 30-day bucket when the real exposure was 350.00. Revenue was recognised at order time for goods that had not transferred, so the month in which it was recognised is also wrong. And the customer’s three-way match, which compares their purchase order, their goods receipt and your invoice, fails on the very first comparison.
Now run the same week with shipment-triggered invoicing. Seven units ship, and an invoice for 350.00 is raised from that shipment. The remaining three stay open on the order. When they ship, a second invoice for 150.00 is raised from the second shipment. Two documents, both correct when issued, both matching a goods receipt the customer can verify. No credit note, because nothing wrong was ever sent.
What the two approaches actually cost
| Invoice from the order | Invoice from the shipment | |
|---|---|---|
| Document raised when | The customer commits | The goods leave |
| Short-ship handling | Credit note against a sent invoice | Invoice matches the picked quantity |
| Backorder handling | Credit note now, new invoice later | Second invoice when the rest ships |
| Cancellation after invoicing | Full credit note, ledger reversal | No invoice exists to cancel |
| Revenue recognition timing | Before transfer of control | At transfer of control |
| Three-way match on the buyer’s side | Fails until corrections net out | Matches the goods receipt line for line |
| Cost of getting it right | Ongoing, per exception | One-time, structural |
The second column is not more work. It is the same work, done once, at the moment the facts are known.
The one case where order-triggered invoicing is correct
Be precise about the boundary. Shipment-triggered invoicing is a rule about goods, and goods have a dispatch event. Not everything does.
A subscription has no shipment. A retainer has no shipment. A fixed-fee service billed monthly has no shipment. For those, the billable event is the passage of the period or the acceptance of a deliverable, and invoicing from a schedule is exactly right. Deposits and prepayments are a third case: a deposit request is a legitimate document that does not assert delivery, and it should be applied against the real invoice rather than replacing it.
The rule generalises cleanly: invoice from whatever document records the thing the customer is being billed for actually happening. For physical goods that document is the shipment. For a service period it is the period. It is never the order, because the order is the request.
Why this cannot be fixed by being careful
You can staff around order-triggered invoicing. Hold the invoice in draft until dispatch, have someone check it against the pick list, release it manually. Plenty of teams do, and it works until volume rises or the person doing the checking is on leave.
What it does not fix is the structural problem: the invoice and the shipment are two records created by two processes in two places, and the only thing keeping them equal is someone comparing them. The moment the invoice is generated by the fulfilment event itself, the comparison has nothing to compare, because there is only one quantity.
That is the same argument that applies to stock reservations and overselling: the reliable fix is not a more careful process around two numbers, it is an architecture where the second number does not exist independently.
How Oneop handles this
For inventory orders, Oneop defers invoicing to shipment deliberately, so you never invoice goods that have not left the building. Shipping a sales order in the inventory module runs as one transaction: it locks the order row, re-validates the status, writes the shipment, decrements stock, posts cost of goods sold as a balanced journal entry, raises the invoice and advances the order status together. Stock and the ledger cannot end up disagreeing about a shipment that half-happened, because there is no intermediate state in which one of them has been updated and the other has not.
The reverse direction holds too. Voiding an invoice reverses its ledger entry and releases the stock it had reserved, in the same action, because both live in the same transaction boundary. That property is a consequence of the invoice, the movement and the journal entry being rows in one database rather than three synchronised systems.
The quantity on the invoice is the quantity on the shipment because they are produced by the same write. Nobody reconciles them. Nobody can, and nobody needs to.
If your orders routinely ship in more than one delivery, the document chain gets longer and the matching gets harder, which is the subject of partial shipments and partial invoices. And once the invoice exists, what it posts to the ledger is the ordinary double-entry machinery: receivables debited, revenue and tax credited, both sides named in one posting.