What data integration actually solves
Data integration connects separate operational and finance systems into one consistent, reconciled dataset. In practice the deliverable is less about connectivity than about agreement: a defined authoritative source for each concept, documented transformation logic, and a reconciliation that ties the result back to the ledger.
This matters because the systems are rarely wrong. The CRM books revenue on close, the ledger on delivery, the operational system on despatch — each correct within its own boundary. Connecting them without resolving that produces a faster disagreement, delivered daily.
ETL or ELT?
| ETL | ELT |
|---|
| Transform | Before load | Inside the warehouse, after load |
| Raw data | Not retained in target | Preserved — reprocessing is cheap |
| Best when | Strict pre-load validation, sensitive fields, very large volumes | Cloud warehouse available, requirements still evolving |
| Main risk | Logic buried in the pipeline, hard to audit | Warehouse fills with untransformed sprawl without governance |
ELT is the sensible default where a cloud warehouse provides the compute, mostly because preserving raw data makes changing your mind cheap. The choice matters less than whether the transformation logic is documented and version-controlled either way.
How we approach it
- Agree the authoritative source per concept. Which system is definitive for revenue, for customer, for product, for headcount — settled with the functions that own them, before any pipeline is written.
- Map the real flow, including the spreadsheets. Undocumented business logic almost always lives in a workbook between two systems. That logic has to be found and made explicit, not bypassed.
- Build with lineage. Every field traceable to its source and transformation, in version control.
- Reconcile to the ledger as a monitored control. Built in from the start, running continuously, not validated once at go-live.
- Instrument and hand over. Failure alerting, data-quality checks, documentation and a walkthrough, so your team owns it.
The hard part of integration is definitional, not technical. Connectors are commodity; agreeing what "customer" means across three systems is the actual engagement.
Who this is for
- Finance teams reconciling between systems by hand every month
- Organisations after an acquisition, running two of everything
- Businesses whose operational data has never been joined to their financial data, so driver analysis is guesswork
- Teams whose reporting is blocked less by tooling than by the state of the underlying data
Where the symptom is accumulated structural shortcuts rather than a missing connection, start with technical debt in finance.
Data integration FAQs
What is the difference between ETL and ELT?
ETL transforms before loading; ELT loads raw and transforms in the warehouse, preserving the original and making reprocessing cheap. ELT is the usual default with a cloud warehouse.
Why do finance and operational systems disagree?
They answer different questions with the same words — different recognition points, each valid in its own boundary. Only definitional agreement resolves it.
How long does integration take?
4–8 weeks for a first pipeline across two or three documented systems, including reconciliation. Source data quality and definitional agreement drive the variance, not the connectors.
Should it reconcile to the general ledger?
For anything financial, yes — as a monitored ongoing control. Data that cannot tie back to the ledger loses trust the first time it is inconvenient.
Can our team maintain it?
Yes — mainstream tooling, recorded lineage, logic in version control. Integration that requires its builder is a dependency, not a capability.
Where this fits
Integration usually follows data strategy and precedes data warehousing and custom analytics. Where systems need to talk to each other continuously rather than through a warehouse, see API development & integration.
