The right way to connect Salesforce to a finance or ERP system depends on three things: which system owns each piece of data, how quickly changes must appear on the other side, and how much data moves. Most organisations end up with a mix of real-time calls, event-driven updates and scheduled batch loads, each used where it fits.
This article explains the main patterns, when each one suits finance and ERP work, and the design decisions that make an integration reliable rather than fragile.
First, decide who owns what
Before choosing any technology, agree which system is the source of truth for each type of record. In a typical arrangement, Salesforce owns prospects, opportunities and the customer relationship, while the finance system owns invoices, payments, credit limits and the general ledger. Customers and products are often shared, which is where most problems start.
Write the ownership down, field by field for shared records. If both systems can edit a customer's billing address, decide which one wins and how the other is updated. Skipping this step produces the classic symptom of a poorly planned integration: records that overwrite each other, and two teams quoting different figures for the same customer.
Real-time request and reply
In this pattern, one system calls the other and waits for an answer. A sales user opens an account in Salesforce and sees the current balance and overdue invoices, fetched live from the finance system. Or a quote is checked against the ERP for stock and pricing before it is sent.
Real-time calls suit lookups and short transactions where the user needs the answer immediately. They are less suitable for large volumes, and they create a dependency: if the finance system is slow or offline, the Salesforce screen is affected. Design for that with timeouts, clear messages to users and a sensible fallback.
Event-driven updates
Here, a system announces that something has happened, and any interested system reacts. When an opportunity is marked as won in Salesforce, an event triggers the creation of a customer and sales order in the ERP. When an invoice is paid, the finance system publishes an event and Salesforce updates the account.
Salesforce supports this through platform events and change data capture, and most middleware can publish and subscribe to events from finance systems. The strength of the pattern is loose coupling: neither system waits for the other, and a new system can subscribe later without changing the original integration. The trade-off is that you must design carefully for ordering, duplicates and retries.
Scheduled batch synchronisation
Batch loads are unfashionable but still the right answer for many finance jobs. Nightly synchronisation of products and price lists, end-of-month invoice history, or a daily reconciliation of payments are all well served by a scheduled job that moves records in bulk.
Batch integrations are simple to reason about, efficient for large volumes and gentle on system limits. The cost is latency: data is only as fresh as the last run. For finance, that is often perfectly acceptable, provided users know when the data was last updated.
Viewing data without copying it
Sometimes the best integration moves no data at all. Salesforce Connect and similar approaches let users view records held in another system, such as invoice lines, from within Salesforce without storing a copy. This avoids duplication and keeps finance as the single source, at the cost of depending on the external system's availability and speed. It suits reference data that users read but rarely report on.
Middleware or direct connection?
Middleware platforms such as MuleSoft, or an integration service already used by your ICT team, add a layer between systems that handles mapping, routing, retries and monitoring. They earn their place when you have several systems to connect, complex mappings, or integrations you want to reuse across projects.
For one or two straightforward connections, Salesforce's own APIs and tools are often simpler and cheaper to run. The right choice is the lightest option that will still be reliable and maintainable in three years, by people who were not involved in building it.
Designing for failure
Every integration will fail at some point: a network drops, a password expires, a record fails validation. What matters is what happens next. Reliable integrations share a few habits:
- Use external identifiers and upsert operations, so a retried message updates a record instead of creating a duplicate
- Hold failed records in a queue for retry rather than dropping them
- Log every exchange with enough detail to trace a single record end to end
- Alert a named person when failures pass a threshold, not just a shared inbox
- Write a runbook that explains how to diagnose and recover from each type of failure
Security for finance integrations
Finance integrations move sensitive data, so treat them with care. Use a dedicated integration user in each system with only the permissions it needs. Store credentials in Salesforce named credentials or your middleware's secure store, never in code. Encrypt data in transit, restrict which network locations can connect, and review access whenever the integration changes. For government organisations, document these controls for your security assessment.
Putting it together
A typical finance integration for a growing organisation might combine all of these: a real-time lookup of account balances, an event that creates a sales order when a deal is won, a nightly batch of products and prices, and a monthly load of invoice history for reporting. Each piece is simple. The design work is in choosing the right pattern for each flow and making failures visible.
If you are planning an integration between Salesforce and your finance or ERP system, start with the ownership map. It costs a few hours and prevents most of the problems that make integrations expensive to fix later. To talk through your systems with an integration architect, call 0494 743 131.