How ERP modules actually integrate

The word integrated hides three different things

Almost every ERP brochure uses the word integrated. Underneath it sit at least three arrangements that behave very differently when something goes wrong at month end. The first is file or scheduled batch transfer: one system exports, another imports, usually overnight. The second is API or middleware synchronisation, where two separate databases stay in step by exchanging messages. The third is genuinely shared data, where the modules are not separate systems at all but different views over one set of tables, one general ledger, and one set of master records.

None of these is universally correct. Batch transfer is cheap, easy to reason about, and survives an outage on either side because the file simply waits. It is also always stale by design, and a failed job can go unnoticed until someone questions a report. API synchronisation gives near-real-time behaviour and lets you keep systems you have good reasons to keep, but you now own a distributed system: retries, ordering, partial failures, and two copies of the truth that can disagree. Shared data removes the class of problem where two databases diverge, because there is only one, but it means the modules must agree on one chart of accounts, one item definition and one release cadence, which is a constraint rather than a free benefit.

The practical question is not which level is best but which level each flow deserves. Nightly transfer of a bank statement is fine. Nightly transfer of stock levels behind a live point of sale is not. Skyline Nexus sits at the third level for its own modules: accounting, point of sale and inventory, CRM, maintenance, HR, fleet and assets write to one ledger and one set of masters, and integrate outward to external systems by API where a customer already has a system worth keeping.

Master data is where drift starts

Integration failures are usually blamed on interfaces, but the first crack is normally a master record that exists twice with slightly different content. Once two systems each hold their own customer list, the lists diverge within weeks, and every downstream number inherits the divergence.

• Customer: one identity across sales, invoicing, receipts and credit control, or aged receivables will not agree with the sales report.
• Supplier: shared across purchasing, payables and payments, including bank details, which are a fraud target when duplicated.
• Item: one code, one unit of measure, one costing method. Two item masters mean two stock valuations.
• Chart of accounts: a single structure. If a module keeps its own account list and maps into yours, the mapping is a second thing to maintain and to get wrong.
• Tax codes: one definition of rate, treatment and effective dates, used by both the transaction and the return.
• Branch and location: shared, because both stock and accounting are dimensioned by it.
• Employee: one record behind payroll, attendance, maintenance work orders and vehicle assignment.
• Asset: one register behind depreciation, maintenance history and disposal.

Subledgers and the control account

A general ledger holds summarised balances. The detail lives in subledgers, and each subledger is tied to a control account in the ledger. Accounts receivable holds a line per customer invoice and receipt, summing to the receivables control account. Accounts payable does the same for supplier bills. Inventory movements post to a stock control account, with cost of goods sold recognised as goods leave. Payroll posts gross pay, employer contributions, deductions and net liabilities. Fixed assets post additions, depreciation and disposals against asset cost and accumulated depreciation. Point of sale posts sales, tax collected, tender types and, where perpetual inventory is used, the cost side of each sale.

The rule that makes this trustworthy is simple: the subledger must always reconcile to its control account, to the currency unit. If the receivables ageing says one figure and the receivables control account says another, one of them is wrong and you cannot know which without investigation. This is why direct journal entries into control accounts are normally blocked. A manual journal into receivables creates a balance no customer owes, and it will not appear on any statement you send.

The reconciliation should be a report you can run on demand, not a spreadsheet someone maintains. When modules share one ledger, the reconciliation is close to tautological. When they do not, it is the single most important check you can automate.

Posting rules and the audit trail

Every ledger line should be traceable back to a source document: an invoice number, a goods receipt, a payroll run, a depreciation schedule, a point-of-sale transaction. If a line exists without a source, someone has bypassed the process. The document identifier should travel with the ledger line, not sit in a separate mapping table.

Posted entries should not be silently editable. Corrections belong in reversing entries or credit notes, which leave both the original and the correction visible, with their own dates and their own users. Period close should lock the period rather than rely on people remembering not to backdate. The test is whether you can take any balance, open it, and walk down to the documents that produced it without leaving the system.

Where integrations actually break

The failure modes are well known and almost always the same ones.

• Timing and cut-off: a sale posted just before midnight on the last day of the period arrives in the other system after the cut-off, so the two periods never match.
• Failed jobs nobody watches: a scheduled transfer stops running and the absence of data looks like a quiet week.
• Partial writes: the invoice header is created, the lines fail, and one side now holds a document the other does not recognise.
• Duplicate keys: a retried message creates a second copy of the same invoice, or a numbering scheme collides across branches.
• Currency and rounding drift: two systems rounding at different points, or using different rates for the same day, produce small differences that accumulate.
• Tax computed twice: the transaction system and the accounting system each calculate tax, using slightly different rules on discounts, inclusive pricing or rounding per line versus per document. The invoice given to the customer and the figure in the return then disagree.

Idempotency and proving both sides agree

Anything that can be retried will be retried, so every posting operation needs a stable key derived from the source document. Sending the same invoice twice must result in one posting, not two. The receiving side should record which keys it has already processed and return the earlier result rather than creating a new one. Without this, ordinary network behaviour turns into duplicate revenue.

Alongside that, you need reconciliation as a first-class feature: counts and totals per period per document type, compared on both sides, with the differences listed rather than summarised. A green tick that only says the last job succeeded is not proof of agreement. The useful report is the one that names the seven documents that exist on one side and not the other.

Branches and currencies

Multi-branch operation means every transaction carries its location as a dimension from the moment it is created, not assigned later by report logic. Stock, revenue, cost and staffing all belong to a branch, and inter-branch transfers need both sides posted or the two branch stock figures will not sum to the company figure. Document numbering must be unique across branches while remaining meaningful within one.

Multi-currency needs the transaction currency, the rate used, and the base currency amount all stored on the line. Storing only the converted figure discards the evidence. Revaluation of open balances and realised gain or loss on settlement then have somewhere to post, and the exchange difference stops being a rounding mystery.

Regional note: clearance changes the timing

Where an e-invoicing regime applies, the timing of integration stops being a design preference. Several tax authorities now require invoices to be cleared or reported to the authority before or as they reach the buyer. The ZATCA regime in Saudi Arabia is a live example: invoices are generated with defined structure, cryptographic elements and identifiers, and the authority is involved in the lifecycle of the document rather than receiving a summary afterwards. That makes invoice creation a real-time integration problem. A nightly batch cannot produce a document the customer is waiting for at the counter.

The picture differs elsewhere, and it is worth being precise. The United States has no federal e-invoicing mandate, and sales tax is administered at state level, with rules and rates varying by state and often by local jurisdiction. Canada operates GST and HST federally with provincial variation, including provincial sales taxes in some provinces. Wider MENA markets are at different stages. The design lesson is to keep tax determination and document issuance in one place, so a market that moves from reporting to clearance changes configuration rather than architecture. Skyline Nexus handles ZATCA clearance from the same transaction that writes the ledger entry, so the invoice the customer receives and the figure in the return come from one calculation.