An ERP–accounting integration needs an agreed owner for each record, a documented posting boundary and a way to reconcile failures. “Synchronise everything” is not a usable requirement. Decide where invoices, payments, parties and adjustments are created, which fields may change elsewhere, and how the receiving system acknowledges each transaction before selecting an integration method.
Let’s plan your accounting integration.
Bring your workflow and the decisions you need to make. We’ll help you define the requirements, examine the trade-offs and plan a practical next step.
Give every record an owner
A system of record is the authoritative place for a particular business fact. It does not mean one application owns every fact. Operations may own a delivery quantity while accounting owns the posted financial entry.
Document both the business owner and the software owner. A finance manager resolves an accounting classification; an integration job transports the decision. Asking the connector to choose between conflicting financial records quietly turns a technical component into an undocumented business rule.
| Record | Illustrative authority | Receiving system may do | Reconciliation evidence |
|---|---|---|---|
| Customer identifier | Agreed master-data owner | Store mapped identifier | Mapping and duplicate-review log |
| Dispatch quantity | ERP | Create a posting request | Dispatch-to-request totals |
| Posted invoice | Accounting | Return reference and status | Accepted, rejected and pending register |
| Payment allocation | Accounting | Update operational visibility | Allocation reference and timestamp |
| Credit adjustment | Approved originating workflow | Link to original entry | Adjustment-to-original relationship |
This is a worksheet to adapt. Do not copy the ownership choices without checking your actual accounting process.
Model the posting lifecycle
Use explicit states such as prepared, submitted, accepted, rejected and awaiting investigation. “Sent” only proves an attempt occurred; it does not prove the receiving application accepted the transaction.
Define what makes a request the same request when retried. Keep a stable business identifier and the receiving reference. If the connection fails after acceptance but before acknowledgement, a blind retry must not create a second invoice.
AWS describes the transactional outbox pattern for coordinating database changes and event publication, including duplicate-message considerations. Treat it as an architectural reference, not evidence that a particular connector implements reliable delivery.
Work through a correction
Imagine dispatch D-104 was accepted by accounting, then the customer returned part of the order. Do not silently overwrite the accepted dispatch or delete the accounting reference. Agree the business correction: a return record, a linked credit request, or another approved mechanism supported by the systems.
Test the full sequence, including a rejected correction and a retry. The operator should see what happened without asking a developer to interpret a queue. Record who can approve the correction and which report confirms the final position.
Build a daily exception report
The report should distinguish accepted items, items not yet attempted, requests awaiting acknowledgement, rejected records and mismatched totals. Include amounts, currencies, business dates and identifiers where relevant. Compare like populations rather than subtracting two grand totals from different time windows.
An exception needs a responsible person, a next action and an ageing rule. Define whether operations may continue while the item is unresolved. A missing invoice classification may need a different response from a duplicated posting.
Questions implementation teams ask
Is a nightly batch good enough?
It can be if operational decisions tolerate the delay and failures are visible. Specify the acceptable lag, cutoff rules and recovery process. “Real time” also needs a measurable freshness requirement and a plan for outages.
Can both systems edit customers?
Only with explicit field ownership or conflict rules. Unrestricted two-way editing creates avoidable ambiguity. Decide how merges, inactive records and identifier changes propagate.
What to prepare
List record owners, example corrections, expected transaction volume and sample rejection messages. Review the API integration requirements checklist alongside your ERP migration plan. Get the posting and reconciliation rules signed off before committing to a connector estimate.
