A manager sees dispatch and marks a deal complete. Finance is still identifying an incoming payment, while the customer disputes quantity. One status hides three unfinished jobs. The trade process owner needs an Order-to-Cash model, from agreed order through reconciled funds, that identifies each fact’s source and the next action owner. The proposed method below uses a hypothetical export order without assuming that an operational status establishes a legal or accounting outcome.
Connect objects before combining their states
Hypothetical order E-17 covers one hundred units at an agreed total price of EUR 10,000. To keep the example bounded, taxes, exchange differences and bank charges are not calculated. Two shipments contain sixty and forty units. The first has receiving evidence; the second has only been handed to the carrier. E-17 remains the control object, but the state of one trip cannot establish fulfilment of the entire order.
Connect the contract, order version, lines, shipments, receiving evidence, invoice and incoming funds. Each object needs its own identifier; one deal may contain several invoices and payments. Select the order system as the source of the commercial promise, warehouse or transport records for physical movements, and the approved financial ledger for balances. Integration carries facts without giving every system permission to change them.
GS1 EPCIS defines a model for sharing visibility events between applications. Its useful principle here is to distinguish an event concerning an object from the aggregate assessment of a deal. The standard does not determine revenue recognition or contractual fulfilment. Authorised specialists resolve those matters under applicable terms, while the operational record preserves the basis used.
Sources: [1]
Freeze the promise and define permitted changes
Before releasing E-17 for fulfilment, the commercial owner confirms quantity, price, currency, locations and agreed conditions. Retain the planning version and its approvers. If the customer changes the second part, show which uncompleted actions need replanning. Already dispatched quantities and previously issued documents must not silently change with a general order field.
Distinguish a requested change from an accepted change. A manager may record the customer’s request, while a defined role approves a new price or deadline. Until approval, the previous confirmed version remains operative. If it can no longer be fulfilled, the operations owner opens an exception identifying the decision required. A generic stopped state is insufficient without the actual blocker.
Partner-facing states need precise meanings. Sixty dispatched means a confirmed warehouse movement; sixty accepted means a verified receiving outcome. Awaiting change approval refers to an open task rather than a manager’s inference. Show the last confirmation time and the limits of available information so an old fact cannot appear to be a current promise.
Separate receipt of money from invoice settlement
The example has an approved invoice for EUR 10,000. A bank confirms receipt of EUR 6,000, but the payment reference names a contract containing other open transactions. Finance initially records the amount as unallocated. Once it is verified against this invoice, the open balance becomes EUR 4,000. This illustrative arithmetic does not prescribe accounting entries for a particular jurisdiction.
Microsoft’s Dynamics 365 documentation distinguishes recording a payment from applying it to an invoice during settlement. This supports separate states in one actual product without recommending that product. In our proposed process, the reconciliation owner examines payer, receiving legal entity, currency, amount, bank identifier and candidate invoices. A similar contract reference alone is insufficient grounds for automatic allocation.
If the customer disputes part of the delivery, retain the dispute alongside the balance instead of deducting money without an authorised decision. The manager assembles evidence, finance determines the permitted financial action and a competent contracts role checks its basis. The table shows work remaining under different combinations of facts. No state should conceal another department’s unfinished task.
↔ Scroll the table horizontally
| Known facts | Work remaining | Owner |
|---|---|---|
| Part of the order dispatched | Confirm remaining fulfilment | Operations coordinator |
| Funds received without allocation | Verify payment reference | Finance |
| EUR6000 applied to the invoice | EUR4000 balance and its due date | Receivables owner |
| Invoice settled but dispute open | Decision on the disputed matter | Authorised case owner |
Sources: [2]
Manage discrepancies and recover data exchange
Create a task for each gap with the deal key, problem type, source and required decision. The operations coordinator owns missing evidence for the second shipment; finance owns an unidentified payment reference. Assignment must be followed by acceptance of the work. A deputy accepts work when its owner is absent, and unaccepted tasks escalate under an agreed deadline appropriate to the consequence.
The exchange contract defines message identifiers, object versions, allowed transitions and repeat handling. Repeated bank records do not increase receipts, and repeated warehouse events do not add shipments. Following an outage, integration support restores technical transmission while the process owner reconciles the business result. Their closure criteria differ: successful transmission does not verify message meaning.
Set reconciliation frequency according to dependent decisions. For the pilot, we propose daily comparison of orders, shipments, invoices and allocated payments through stable keys. The operations manager reviews all gaps, their owners and next actions. Internal policy determines resolution deadlines. A missed deadline creates visible escalation rather than changing a financial balance.
Accept complete and partial outcomes
Prepare E-17, both shipments and the invoice. Test partial receiving first, then an unallocated payment, approved allocation and the EUR 4,000 balance. Add a dispute, a repeated message and late evidence for the second shipment. Define expected changes, remaining open work and task ownership before the test. Otherwise the demonstration establishes only that fields can be changed.
Retain data versions, event history, reconciliation records and exception decisions. Commercial ownership confirms the promise, operations confirms physical facts and finance confirms balances. Permit overall closure only under an agreed rule covering all required process elements. Warranty or claims work should remain separately visible even after the principal cycle ends.
Start with a bounded group of deals whose results can be reproduced manually. Check whether another manager can understand the record without a telephone explanation from its author. Add the missing basis if they cannot, rather than inventing another general status. A useful next step is to select a deal that departments describe differently and identify the facts behind each answer.
Action checklist
- Define contract, order, shipment, invoice and payment keys and their relationships.
- Retain the confirmed promise version and authority for each change type.
- Separate receipt, payment allocation, open balance and dispute.
- Assign gap owners and test repeats, recovery and final reconciliation.
Questions and answers
Must the entire cycle run in one system?
It needs agreed fact ownership and transition rules. Several systems can support the cycle if the shared view exposes data origin, freshness and unresolved contradictions.
Can a deal close after full payment?
Full payment closes only the defined financial element. Overall completion depends on the agreed rule for fulfilment, documents and open exceptions, which require separate checks.