An order has at least three clocks.
The commercial clock advances when a customer accepts the deal. The physical clock advances when stock is reserved, picked, shipped, returned, or written off. The accounting clock advances when the ERP posts a document into an open period. Those clocks may be seconds or days apart.
ERP integration services go wrong when a project treats them as one timestamp called “synced.” A green arrow between ecommerce and the ERP says nothing about a shipment that split across warehouses, a payment captured before an order was rejected, or a correction that arrived after period close.
The buyer needs a three-clock ledger before a system diagram. The ledger names each business occurrence, which clock it advances, which system records it, and how the other clocks catch up.
Build the ledger from a real transaction
Select one transaction with an awkward history. A clean order teaches very little. Use a partial shipment, substituted item, tax correction, rejected payment, return, or backorder.
Lay out what happened in time order:
| Clock | Event | Authority | Evidence |
|---|---|---|---|
| Commercial | Order accepted or changed | Commerce or order system | Order version and customer commitment |
| Physical | Quantity reserved, moved, shipped, or returned | ERP or warehouse system | Inventory movement and shipment identity |
| Accounting | Invoice, credit, receipt, or journal posted | ERP finance module | Document number, period, and posting state |
This is a proposed scoping tool, not a claim about one ERP product. Add clocks when the business has other independent facts, such as regulatory release or installation at a customer site.
For every event, record a stable event ID, business document ID, prior version, effective time, observed time, amount or quantity, and correction link. Those fields let an operator tell a new event from a retry and a correction from a duplicate.
Decide where each fact is born
An integration can copy a field without owning its meaning. The order system may own the customer’s requested quantity. The warehouse owns what was picked. Finance owns the posted receivable. Sending all three into the ERP does not make the ERP the birthplace of all three.
Mark one system as authoritative for each fact and one service as the permitted writer at each destination. If two services can update the same inventory reservation, write the conflict rule before build.
Microsoft’s Dynamics 365 integration guide separates options such as data entities, dual-write, and business events and ties them to different external-system needs. The useful lesson is not to copy a Microsoft design into another ERP. It is to select an interface from the business occurrence, timing, and destination rather than from a generic preference for APIs.
Keep events small and corrections explicit
An event should say what happened, not attempt to carry an entire ERP export. Microsoft makes the same distinction in its finance and operations guidance: business events notify external systems about business actions and are not intended as a large-data export mechanism.
The payload needs enough identity and context for a consumer to find the authoritative record. Large snapshots can create a second, stale version of the ERP object inside the message layer.
Never edit history to make a correction disappear. Link a credit to the invoice it corrects. Link a return to the shipment. Link a replacement order to the rejected version. The three-clock ledger should show both the original event and its repair.
Design for partial advancement
The most useful test stops the transaction after one clock moves.
Try these cases:
- The commerce system accepts an order, but inventory reservation fails.
- The warehouse ships part of an order, but the invoice post times out.
- The ERP accepts a write, but the caller loses the response and retries.
- A correction arrives after the accounting period closes.
- Two workers process the same event at the same time.
For each case, state what the customer sees, what operations may do, which action is forbidden, and how finance learns the final state. A retry should not rely on hope. Use the event and business-document identities to determine whether the intended effect already exists.
Concurrency is also a commercial constraint. Oracle documents account-level concurrency governance for NetSuite web services and RESTlets, including monitoring, violation errors, and retry guidance. A provider should verify current limits in the buyer’s actual account and model peak behavior. Never copy a limit from a slide into the design.
Treat close as a system boundary
Month-end close changes what an integration is allowed to do. An operational correction may be valid while a direct post into a closed period is not.
Ask finance to define:
- the cutoff for ordinary postings;
- who may reopen or adjust a period;
- how late physical events are represented;
- which corrections need approval;
- how subledger and general-ledger totals are reconciled;
- what evidence an auditor or controller expects.
Do not encode an accounting workaround without the controller’s approval. The integration can route a late item to a queue. It cannot decide that a journal entry is the correct business treatment.
This boundary also belongs in non-production tests. Use representative period states and synthetic records. A happy path run during an open test period proves nothing about close.
Separate movement from agreement
Message delivery, API success, and business agreement are three different measurements.
Monitor transport so the team knows when calls or messages fail. Monitor processing so it knows which events are pending, rejected, or retried. Then reconcile the business facts independently:
- accepted order quantity against reserved and shipped quantity;
- shipped amount against invoiced amount;
- captured payment against the settled and posted amount;
- returned quantity against received stock and issued credit.
Reconciliation should group by stable business identity and accounting period. A daily count can hide a large-value mismatch. A total amount can hide two equal and opposite errors.
Assign each exception class. Operations may resolve an invalid ship-to location. Finance may decide a posting correction. Engineering may repair a schema or authentication failure. “Integration team” is too vague when money or stock is already wrong.
Rehearse recovery at peak shape
A proof should use the buyer’s peak transaction shape rather than average volume alone. Include the largest order, most lines, busiest interval, and the slowest permitted downstream response. Verify that throttling does not turn one retry into a swarm.
Run the system down, accumulate a backlog, restore it, and watch the three clocks converge. The operator should be able to answer:
- Which business events are waiting?
- Which effects already happened?
- What will the replay attempt?
- Which record needs a person?
- When is the backlog safe to declare closed?
If those answers require database edits by the original developer, the service is not ready for handoff.
Buy an operating boundary
Normalize provider proposals around the same transaction and test packet. Require the following deliverables:
| Deliverable | Acceptance evidence |
|---|---|
| Three-clock ledger | Real transaction, authority, identities, correction links |
| Interface decision | Timing, pattern, current product constraints, rejected alternatives |
| Security design | Dedicated identities, minimum actions, credential lifecycle |
| Failure design | Partial advancement, safe retry, duplicate defense, close behavior |
| Reconciliation | Independent comparisons and exception ownership |
| Operations | Dashboards, queues, runbooks, support window, recovery drill |
| Transfer | Repositories, deployment, configuration, documentation, and exit test |
The provider should name what remains unknown. An ERP integration quote issued before anyone has traced a transaction is not fixed price. It is deferred discovery with a number attached.
The first gmware workshop
Bring one awkward transaction, the three system owners, a recent reconciliation spreadsheet, and the person responsible for close. We would map the clocks, identify the authoritative facts, and choose one partial-failure test.
That workshop may point to a native connector, an integration platform, a custom service, a process fix, or a smaller scope. The useful output is not a prettier architecture diagram. It is a transaction everyone can explain before and after it breaks.