Finance Systems Integration Map: ERP, CRM, Billing and Banks

Finance systems rarely fail because no connector exists. They fail when two applications can update the same financial fact, a message is retried without knowing whether the first attempt posted, or a technically successful transfer has no completeness check.

A useful integration map therefore starts with business objects and control states, not product logos. It should show which system is authoritative, what crosses each boundary, when the transfer occurs, how success is proved and who owns an exception until it is cleared. Where a coordination layer spans several of those boundaries at once, orchestration read and write design separates the reference data it should read from the narrow set of records it should be permitted to write.

Choose the integration pattern by control need

An integration pattern is the operating method used to move or expose data between systems. Salesforce’s integration-pattern guide distinguishes synchronous, asynchronous, batch and virtual approaches and advises selecting among them based on factors including volume, failure handling and transactionality. That is a better starting point than making every interface real time.

For APIs, OpenAPI Specification 3.2.0 provides a formal description of an API’s surface and semantics. For event exchanges, CloudEvents 1.0.2 defines a vendor-neutral event format and requires identifying context such as source and event ID. These standards can make the contract inspectable, but they do not decide the finance owner, control total or exception process.

The finance systems integration map

A finance systems integration map is a controlled inventory of data and status handoffs among operational platforms and financial records. It shows authority, direction, timing, pattern, control evidence and accountability for every material interface.

CRM
  | approved account, quote and commercial state
  v
Billing or contract platform
  | invoice, credit and billing lifecycle
  v
ERP, subledger and general ledger -------- approved payment instruction --------> Bank
  ^                                                                              |
  |                                                                              |
  +------ invoice, payment and hold status ------ CRM or service teams           |
                                                                                  |
Bank and payment channel <------ acknowledgements, rejects, statements and transactions
                                  |
                                  v
                          ERP or treasury platform

Across every arrow:
contract | authoritative ID | timing | count/value control | failure owner |
safe retry | reconciliation | monitoring and evidence
  

The diagram is deliberately directional. Bidirectional integration should mean two governed flows with different objects or permissions, not two systems freely overwriting the same fields. A customer-facing application may display invoice and payment status, for example, while the billing or ERP record remains authoritative. Entitlement is the harder instance of the same rule, so which system owns the subscription and entitlement state has to be settled before the product, the billing platform and the CRM each hold a copy.

For customer order, invoice, receipt and payment-status boundaries, the order-to-cash control map supplies the business handoff and acceptance context around those interfaces.

Assign system-of-record ownership at the object level

A system of record is the application authorised to establish the accepted state for a defined business object. The owner may differ by object and, in some cases, by field. The table below is a starting design assumption, not a universal product rule. The same rule applies when an AI agent can update a workbook: AI research and spreadsheet-change controls should distinguish source authority, proposed changes and the approved financial record.

The broader finance technology stack reference architecture helps define the layer and lifecycle state in which each governed object belongs before interfaces are designed.

The ownership record should name the business data owner, the technical interface owner and the team that clears exceptions. Those are three different duties. It should also identify the stable cross-system key used to relate replicas without treating local database IDs as interchangeable. Beyond the interface itself, what a business data owner is accountable for covers definitions, chart of accounts and dimension governance, master data, quality thresholds and control evidence.

Interface ownership and control matrix

The matrix below converts the map into an operating specification. Replace each default with the actual systems, cut-offs and teams in scope. Where a single row contains both an outbound command and an inbound status, document them as separate interfaces in the build register even when one connector carries both.

Treat receipt, acceptance, settlement and reconciliation as different states

A single field called “success” is inadequate for financially relevant flows. The minimum state model should distinguish:

The Nayax–IPS settlement acceptance test applies those states to parking payments, where processor acceptance, operator payout and bank reconciliation must remain separate evidence points.

1. Approved: the source system has completed its own authorisation and created a transferable record.
2. Sent: the source or integration service attempted transmission.
3. Received: the channel or destination acknowledged technical receipt.
4. Accepted or rejected: the destination applied its business and schema rules.
5. Posted: the destination created the intended operational or accounting record.
6. Settled: the bank-confirmed movement reached the relevant account state.
7. Reconciled: independent evidence matched the source instruction, destination record and financial result.

Corporate payment messages illustrate why the distinctions matter. Swift’s corporate ISO 20022 guidance identifies pain.001 for payment initiation, pain.002 for customer payment status, and camt.052, camt.053 and camt.054 for cash reporting. They serve different control questions. A status response is not the same evidence as a bank-account transaction.

Message identity must persist across the chain. The ISO 20022 Business Application Header brings sender, receiver, message identity and reference data into a consistent header. Even outside ISO 20022, the interface design should preserve an equivalent correlation reference from source approval through final reconciliation. The planned Revolut customer migration shows why legal-entity and account identifiers also need effective-dated mappings through a bank-feed cutover.

Design retries so they cannot create duplicate finance events

A retry policy starts by classifying the failure. A network timeout or temporary service outage may be transient. Invalid terms, a closed period, a missing account or a bank rejection is a business failure. Retrying the second class without changing the record repeats the same error and can obscure ownership.

Microsoft’s Retry pattern guidance warns that a non-idempotent operation may execute more than once when the first request succeeds but its response is lost. The control response is not “never retry.” It is to make the command safely repeatable or to prove that it did not execute before another attempt.

• Use a stable idempotency key derived from the business object, operation and version, not a new random key for each attempt.
• Store the processed key and resulting destination identifier so a duplicate request returns the prior result rather than creating another record.
• Cap attempts and delay repeated calls; after the limit, move the item to an owned exception queue.
• Carry sequence or version data so consumers can reject stale updates and detect gaps.
• For a corrected business record, create a new governed version and retain the rejected version’s history.

Messaging infrastructure may redeliver. Microsoft’s asynchronous messaging guide notes that duplicate command processing can create outcomes such as duplicate orders or double billing and that ordered delivery requires an explicit mechanism. Finance consumers should therefore be idempotent even when the broker offers duplicate detection.

Reconciliation is a separate control, not a monitoring metric

Monitoring asks whether an interface is running. Reconciliation asks whether the intended business and financial result is complete and accurate. An API can have no errors while one approved invoice never reaches the ledger. A file can be received while one record is rejected. Both interfaces may look technically healthy. Northern Trust’s Lukka agreement provides a current digital-asset example: coverage across many sources does not by itself prove that the complete population was accepted, normalized and reconciled. That gap is also a sequencing rule for the wider chain, since completeness is the first record-to-report control to automate before any later stage can be trusted.

Build reconciliation in three layers:

1. Transfer completeness: compare source and destination counts, values, IDs, sequence and hash or checksum where relevant.
2. Business-object state: compare the authoritative object with its created record or replica, including version, effective date and status.
3. Financial result: match billing to subledger and ledger, payment release to bank status and statement, and bank statement to cash-book and GL balances.

Control totals should be designed for the object, not copied mechanically from another interface. As one concrete payments example, the European Payments Council’s 2023 SCT implementation guidelines define a number-of-transactions field and a control sum of individual amounts. That example is scheme- and message-specific, but the principle is broadly useful: compare both record population and financial value.

Build monitoring around business completeness

Each interface needs technical telemetry and a business health view. Microsoft’s observability guidance describes logs, metrics, traces and correlation IDs as the basis for following a transaction across components. For finance, that correlation should reach the business object and control state rather than stopping at an infrastructure request.

At minimum, capture:

• interface, source, destination, object type and legal entity;
• business object ID, message or file ID, correlation ID and source version;
• source event time, receipt time, processing time and final-state time;
• count, value, currency and status-reason data where financially relevant;
• attempt number, prior result, destination identifier and exception owner;
• runbook, escalation threshold and evidence-retention rule.

Useful business metrics include expected versus received count and value, oldest unprocessed item, rejected value, duplicate attempts, out-of-sequence messages, unposted invoice value, payments without a terminal bank state, missing statements and unmatched bank value. The dashboard should link each alert to the affected records and the responsible queue. The AUSTRAC Cryptolink suspension gives that design an operating-access consequence: AUSTRAC linked missing threshold reports and an unanswered information request to a three-month registration suspension.

Logs also need an operating process. NIST SP 800-92 frames log management as an enterprise practice covering infrastructure and ongoing processes. Retention, access and evidence requirements should be set by the organisation’s security, accounting and regulatory policies; an interface team should not invent them locally.

Implement the map as a controlled rollout

1. Inventory the interfaces. List each source, destination, business object, direction, current method, frequency and owner. Split commands, status responses and reporting flows.
2. Set authority and write permissions. Choose the system of record at the object or field level, define the cross-system key and make replicas read-only where appropriate.
3. Select the pattern and timing. Use immediate calls only where the next decision requires an answer. Use durable events or batches where recovery and throughput matter more than instant response.
4. Define the state model and controls. Name every status, message or batch identifier, count, value, sequence, acceptance response and reconciliation point before coding.
5. Assign failure ownership. Separate transient, data, policy, accounting-period and bank rejections. Set retry limits, suspense queues, correction routes and escalation times.
6. Build reconciliation and monitoring together. Technical alerts, transfer controls and financial reconciliations need connected identifiers but distinct owners and close conditions.
7. Test the control cases. Test duplicates, timeout after destination success, partial batch acceptance, out-of-order events, missing status, stale master data, closed periods, replay and bank-statement gaps. Require finance and technology sign-off on the evidence produced.

The completed interface matrix should become a governed design record. Update it when a system, bank channel, message version, business owner, cut-off, retry rule or reconciliation method changes, and use it as the acceptance baseline for every new connector.