Reconciling two records starts by matching the time scope, filters, and comparison units. A transfer control total is a useful first test, but it is not sufficient evidence of a match: two errors can offset each other in the total. Compare record counts and identifiers alongside totals, then apply agreed rules for differences.
This approach applies to transfers between an ERP and another system, between operational and accounting records, and to import, export, and integration controls. The purpose is not merely to confirm a total amount. The purpose is to establish which items are included, who decides on deviations, and when the result can be accepted.
A report name, export date, or total value is not enough for a reliable comparison. Two records may look comparable while differing in at least one material dimension: time of creation, document status, currency, organisational unit, transaction type, or treatment of reversals.
Before the first calculation, document the comparison snapshot:
Without this snapshot, the team may be comparing different data sets. In that case, even a matching transfer control total may be a coincidence.
A transfer control total usually includes a record count and one or more aggregated values, such as quantity, net amount, tax, or gross amount. For each value, specify the unit of measure, currency, rounding rule, and treatment of negative lines.
A minimum set of checks can include:
Aggregates quickly indicate whether an issue exists, but they do not necessarily show where it exists. For example, one line may be missing while another is recorded twice with the same amount. The total amount can remain unchanged even though the record content does not match.
For this reason, reconciling integrated records should also include identifier comparison. A useful output is a list of identifiers found only in the source, only in the target, or in both systems with different key values. Where a business key is not unique, agree a composite key before comparison, such as document number, line number, company, and business date.
The source-data owner confirms the scope and provides the data or a controlled export. The target-record owner confirms a comparable export for the same scope. If the systems cannot produce data at the same time, record both extraction times and assess records within the transition period.
For repeatable control, use a versioned form containing the source name, export parameters, extraction time, and responsible person. This record supports repeat checks after a change to the integration or a business rule.
Before comparing, align date formats, currency codes, decimal precision, status codes, and rules for blank values. Normalisation must not conceal a difference. Describe every transformation and obtain approval from the business-rule owner.
Reversals, partial deliveries, multi-currency documents, post-posting corrections, and retransmissions require particular attention. These cases can be valid business exceptions, but they need a recognisable trace in both records.
Compare the record set first, then compare values within the shared set. Separate the result into three lists:
This order prevents a false conclusion based on an equal total. It also reveals duplicates, provided that the comparison includes the number of occurrences for each identifier, not only its presence.
For every group of differences, establish a classification: expected processing delay, permitted business exception, source-data error, mapping error, failed transfer, duplicate, or unresolved case. Classification is not a technical assumption. It is a business decision with a named owner.
Hypothetical scenario: the source records a shipment at 23:58 and the target receives the message after midnight. If the comparison scope is a calendar day, the records can differ even though the transfer may not have failed. A rule may include a processing time window or treat such records as expected transitional exceptions. Approve the rule before the control, not after a difference appears.
A control ends with a decision, not merely with a file of differences. The responsible person should confirm acceptance, rejection, or conditional acceptance with open exceptions. Retain the comparison parameters, control totals, identifier list, exception explanations, and decision date with that decision.
Database constraints can support checks for uniqueness, required fields, and relationships between records. For example, PostgreSQL documentation describes constraints including uniqueness, NOT NULL , and foreign keys: PostgreSQL Constraints .
These controls reduce some technical risks, but they do not replace business rules. A database can check whether a partner exists or whether a key is unique. It cannot independently determine whether a document in a particular status may be transferred, how to treat a partial delivery, or which period belongs to a particular calculation. Define these rules separately with the business-process owner.
Define the following before starting:
An acceptance measure should be verifiable from retained inputs and comparison results. A statement such as "the difference is small" is not a criterion without a defined threshold, decision owner, and exception record.
When differences recur, the issue is often not limited to a query or export. Review when a record is created, who owns the data, how status changes are governed, and how an exception moves through the process. Business process screening can provide a structured starting point for identifying these points before changing an integration or ERP record.
For an initial reconciliation, select one clearly bounded flow, document the comparison snapshot, and run identifier checks alongside control totals. The result then provides a basis for deciding whether to correct data, change a rule, or adjust the integration.