Troubleshooting common ERP integration errors

An enterprise resource planning system connects finance, inventory, purchasing, sales, payroll and customer data in one operational environment. When that connection works properly, information moves between applications with little manual effort. When it fails, staff may see duplicated orders, missing invoices, incorrect stock balances or reports that do not reconcile.

Integration problems usually come from a small group of causes: incompatible data formats, authentication failures, unclear ownership of records, timing conflicts and weak error handling. The symptoms can look similar, so resolving them requires a methodical process rather than repeatedly restarting the connector or re-sending every failed transaction.

Australian businesses also need to account for GST, Australian Business Numbers, local date formats, state-based operations and systems such as Single Touch Payroll. A reliable investigation considers the technical error, the business process behind it and the conditions under which the information was created.

Start with the failed transaction

The fastest way to narrow down an ERP connection problem is to identify one specific failed record. Use its order number, invoice ID, employee ID or stock-keeping unit to trace the transaction through the source application, integration platform and destination ERP. Examining a single example prevents a broad error message from hiding several unrelated faults.

Check when the record was created, which user or system created it, and whether it was edited before the integration ran. Compare the source payload with a successful transaction from the same workflow. Important differences may include a blank customer code, an invalid tax category, a missing warehouse location or a value that exceeds the destination field’s length.

Integration logs should show the request, response, timestamp and correlation ID without exposing passwords or payment details. A status such as “400 Bad Request” generally indicates invalid data, while “401 Unauthorised” or “403 Forbidden” points towards credentials or permissions. A “404 Not Found” may mean that an endpoint, record or API version is incorrect, whereas a “500” response often requires investigation by the receiving service.

Do not assume that a transaction labelled as failed was never processed. Network interruptions can occur after the ERP accepts a request but before the sender receives the response. Check the destination system before retrying, or an invoice could be created twice. Idempotency keys, unique external IDs and duplicate detection rules help make retries safer.

Resolve authentication and access faults

Credentials are a common source of integration downtime. API keys may expire, OAuth tokens may require renewal, and service accounts can be disabled when an employee leaves the business. Password rotations, multi-factor authentication policies and changes to an ERP security role can also interrupt an integration that had been stable for months.

Confirm that the connector is using the intended environment. A token created for a testing tenant will not usually authenticate against production, even if both environments have similar names. Check the base URL, tenant ID, company code and API version in the integration configuration. Australian organisations operating multiple entities may also need to verify that the account has access to the correct ABN or trading entity.

Permissions should follow the minimum access required for the workflow. An inventory feed may need permission to read products and update stock, while a finance integration might need to create invoices but not change supplier banking information. Broad administrator access can conceal the real requirement and create unnecessary security exposure.

When an authentication error appears intermittently, inspect token caching and clock settings. A server with an incorrect time zone or a token refresh process that runs too late can produce sporadic failures. Systems operating across Sydney, Melbourne, Brisbane and Perth should store timestamps consistently, preferably in UTC, while displaying local times for staff. This avoids confusion when Australian Eastern Daylight Time begins or ends.

Correct data mapping and validation

Mapping errors occur when two systems describe the same business concept differently. One application may use “customer number”, another may use “account code”, and a third may require an internal numeric ID. The integration must translate these values deliberately rather than relying on similar field names.

Tax treatment deserves careful attention in Australia. A product may be GST-free, input-taxed or taxable, and the source platform’s tax code may not match the ERP’s code. A simple text value such as “GST” can be interpreted differently across systems. Validate the tax rate, tax-inclusive or tax-exclusive pricing, rounding rules and treatment of freight before sending financial transactions to the general ledger.

Address and contact data can cause less visible failures. Australian postcodes are numeric but may begin with zero, so storing them as numbers can remove an important digit. State abbreviations, suburb names and country codes should be validated against the destination system’s accepted values. A Melbourne address that arrives with an unrecognised state label may fail customer creation even though the rest of the record appears correct.

Use a canonical data model where practical. Define which system owns each field, the permitted format, whether it is mandatory and how blank values are handled. Apply validation before transmission, then return a useful error that identifies the record and field. “Invalid payload” is much less helpful than “Invoice 48291 requires a tax code for line 3”.

Manage timing, duplicates and incomplete records

Many ERP integrations fail because related records arrive in the wrong order. An invoice may be sent before its customer exists, or an order may reference a product that has not yet been synchronised. Batch schedules can make this worse when one process runs every fifteen minutes and another runs hourly.

Establish dependencies between data flows. Customer and product master data generally need to arrive before sales orders, while fulfilment and payment updates depend on the order being accepted. Where real-time processing is unnecessary, a queue can hold dependent records until the required reference data becomes available. The queue should have a clear retry policy rather than attempting the same request indefinitely.

Duplicates often appear after a timeout, manual reprocessing or overlapping scheduled jobs. Every transaction should have a stable external reference, such as the source order ID, and the destination should reject or safely update a record that has already been accepted. Matching on descriptions or customer names is unreliable because spelling and formatting can vary.

Partial updates require a defined recovery process. If an order is created but its stock allocation fails, staff need to know whether the integration will retry the allocation, reverse the order or place it in an exception queue. A successful HTTP response does not necessarily mean the complete business process succeeded. Monitor each meaningful stage, including validation, posting, acknowledgement and reconciliation.

Build monitoring and reconciliation into operations

A connector should be monitored as an operational service, not treated as a background script that only receives attention after someone notices missing information. Track successful and failed requests, processing time, queue size, retry count and the age of the oldest unprocessed item. Sudden changes in these measures can reveal a problem before it affects end-of-month reporting.

Alerts should be specific enough to support action. A notification that says “integration error” creates unnecessary investigation, while an alert identifying the affected workflow, error category and number of records gives an operations team a useful starting point. Separate transient faults, such as a temporary network outage, from permanent data errors that require correction.

Reconciliation confirms whether the two systems agree after processing. Compare order counts, invoice totals, payment amounts, inventory quantities and GST values over a defined period. A daily comparison may be appropriate for a smaller Australian retailer, while a high-volume distributor in Sydney or Melbourne may need hourly checks for stock and order status.

Document the ownership of each integration and the escalation path for unresolved exceptions. Finance should own decisions about ledger and tax treatment, warehouse teams should own stock corrections, and technical staff should manage credentials, queues and API behaviour. During Australian public holidays or end-of-financial-year processing, agreed support coverage is especially important because a delayed feed can affect payroll, supplier payments or business activity statements.

A controlled change process reduces repeat failures. Test mapping changes in a non-production environment, use representative Australian addresses and GST scenarios, and record the expected result before deployment. Keep API versions, field definitions and retry settings under version control. With clear diagnostics, dependable validation and regular reconciliation, ERP integrations become easier to maintain and far less likely to turn a routine transaction into a costly manual investigation.