Salesforce Data Reconciliation Testing
Salesforce data reconciliation testing is the definitive proof that an integration worked: it compares the record that left Salesforce with the record that landed in the target system — by count, by field and by totals — and flags any discrepancy. Where a functional test confirms a message was sent, reconciliation confirms the data arrived intact.
SyntraFlow is Oracle-native and expanding into Salesforce, so it is designed to read and compare both ends of a cross-system flow.
The gap a functional test leaves behind
Most integration tests stop at "the call succeeded." A record was submitted, an API returned a 200, a Flow completed without error. But a successful call is not the same as correct data. A record can be sent and still arrive with a truncated field, a rounded total, a dropped line, a different currency, or as a duplicate created by a retry. None of those failures shows up as an error — they show up later, in a report, a ledger, or a customer dispute.
Reconciliation closes that gap. Instead of trusting the mechanism, it inspects the outcome: it reads the source record in Salesforce and the destination record in the target system and asks whether they actually agree. This is the discipline at the heart of Salesforce integration testing — proving the join by its result rather than assuming it.
The distinction matters most where the two systems disagree only slightly. A total that is off by a rounding cent, a name that is truncated at a character limit, a status code translated to the wrong value, or a single record dropped from a batch of thousands will all pass a mechanism-level check without complaint. These are the defects that erode trust in an integration over time, because they accumulate quietly until a reconciliation report finally makes them visible. Framing the comparison conservatively — agreeing tolerances up front, and reporting divergence rather than judging intent — keeps the result something both the sending and receiving teams can accept as fact.
Three levels of reconciliation
Reconciliation is not a single check but a ladder of increasingly precise comparisons. Each level catches a different class of defect, and thorough coverage uses all three.
Count reconciliation
Did the same number of records arrive as were sent? Catches dropped messages, filtered records and duplicates created by retries — the coarse but essential first pass.
Field-level reconciliation
For each matched record, do the individual values agree? Catches truncation, mapping errors, format drift and mistranslated codes that a count alone would never reveal.
Total reconciliation
Do aggregates — sums, quantities, amounts — match across the boundary? Catches rounding, currency and tax differences that make two ledgers disagree even when every record is present.
Reconciliation types and what each checks
A focused view of the comparison types, what they verify, and the defects they are designed to surface.
| Reconciliation type | What it checks | Defects it surfaces |
|---|---|---|
| Record count | Number sent equals number arrived. | Dropped records, silent filtering, duplicates from retries. |
| Key matching | Every source key has one destination match. | Orphaned records, broken identifiers, missing counterparts. |
| Field value | Each mapped field agrees on both sides. | Truncation, mapping errors, format and code drift. |
| Numeric total | Sums and quantities aggregate to the same value. | Rounding, currency and tax divergence. |
| Status / state | Lifecycle state is consistent across systems. | Stale status, updates that never returned. |
| Timeliness | Records arrive within the expected window. | Lag, stuck queues, partial batch completion. |
The exact fields, keys and tolerances are aligned to each customer's landscape during a proof of concept.
When reconciliation belongs in your testing
Reconciliation is worth running at several distinct points, each guarding against a different risk.
Post-integration checks
Immediately after a record crosses a real-time or event-driven integration, reconcile the single transaction to confirm it landed correctly before the next step depends on it.
Batch and scheduled jobs
After a nightly or scheduled sync, reconcile the whole set by count and totals so a partial or failed batch is caught the next morning, not weeks later.
Data migration
During a migration or cutover, reconcile source against target to prove the move was complete and faithful before the old system is retired.
Release regression
After a Salesforce seasonal release or a change on either platform, rerun reconciliation to confirm the integration still produces matching data.
Cross-system processes
As part of an end-to-end flow such as order-to-cash, reconcile each handoff so a divergence fails the test rather than surfacing in finance.
Ongoing assurance
As a periodic health check on a live integration, sampling records to confirm the two systems have not quietly drifted apart over time.
How a reconciliation check runs
SyntraFlow is designed to compare both ends of a flow and report exactly where they agree or diverge. This capability is available for demonstration and proof-of-concept validation against your landscape.
Read the source
The originating Salesforce records are captured with the fields and keys that define what should have crossed the boundary.
Read the destination
The corresponding records in the target system are read on their own terms, so the comparison reflects what actually landed.
Match on shared keys
Records are paired on their correlating identifier so like is compared with like, and any unmatched record on either side is flagged.
Compare and report
Counts, fields and totals are compared within defined tolerances, and every discrepancy is reported clearly rather than buried.
Reconciliation needs both ends — and both ends is the point
A reconciliation check is only as good as its access to the destination. Many Salesforce testing tools can read the source but go dark the moment data crosses into an ERP, leaving the most important half of the comparison unverified. SyntraFlow was built Oracle-native and is expanding into Salesforce, so reading and comparing the Oracle side — orders, invoices, balances — is a founding strength, not a blind spot. The same discipline extends to SAP, NetSuite and Workday destinations.
See the back-office depth in the Oracle ERP testing tool, and how reconciliation completes a full flow in Salesforce to Oracle integration testing.
What reconciliation gives you
Proof, not assumption
A passing reconciliation is evidence that the data agreed on both sides, so an integration is trusted because it was verified rather than because it did not error.
Defects caught early
Truncation, rounding and dropped records are found in testing, before they reach a report, a ledger or a customer.
A clear trail
Every comparison leaves a record of what matched and what diverged — the kind of evidence finance and audit can rely on.
Related pages
Integration Testing
The parent discipline that proves Salesforce works with everything around it.
Salesforce–Oracle Integration Testing
Where reconciliation completes an end-to-end order-to-cash flow across both systems.
Cross-System Test Data
Coordinated records on both sides give reconciliation a known, matchable baseline.
Salesforce data reconciliation testing FAQs
What is Salesforce data reconciliation testing?
It is the practice of comparing the record that left Salesforce with the record that landed in the target system — by count, by field and by totals — and flagging any discrepancy. Where a functional test confirms a message was sent, reconciliation confirms the data arrived intact, so an integration is verified by its result rather than assumed to be correct.
How is it different from ordinary integration testing?
Ordinary integration testing often stops when a call succeeds or a Flow completes without error. Reconciliation goes further and inspects the outcome, reading both the source and destination records and asking whether they actually agree. It catches silent defects — truncation, rounding, dropped records, duplicates — that a successful call would never reveal.
What levels of reconciliation are there?
Three build on each other. Count reconciliation checks that the same number of records arrived. Field-level reconciliation checks that each mapped value agrees on matched records. Total reconciliation checks that aggregates such as sums and quantities match across the boundary. Thorough coverage uses all three, because each catches a different class of defect.
When should reconciliation run?
At several points: immediately after a real-time integration, after a batch or scheduled sync, during a data migration or cutover, as regression after a Salesforce seasonal release, and as a periodic health check on a live integration. Each point guards against a different risk, from a single stuck message to a whole failed batch.
Why does reconciliation need access to both systems?
Because the comparison is only as good as its access to the destination. Reading the Salesforce source is straightforward, but the answer to "did it arrive correctly?" lives in the target system. SyntraFlow is Oracle-native and expanding into Salesforce, so reading and comparing the Oracle side is a founding strength. This capability is available for demonstration and proof-of-concept validation.
Does SyntraFlow replace our existing integration tests?
No. Reconciliation complements functional and integration tests rather than replacing them. Functional tests prove the mechanism runs; reconciliation proves the data agrees. Together they give a fuller picture, and the reconciliation capability is aligned to each customer's landscape during a proof of concept.
Prove your integrations by their result
See how SyntraFlow is designed to compare both ends of a cross-system flow and flag every discrepancy before it reaches a ledger.