Reconciliation node

Purpose

A configurable workflow component that provides a standardized and auditable way to match records across datasets:

• Link records using unique identifiers or predefined matching rules
• Identify matched, partially matched, and unmatched records, while preserving unmatched records for future workflow runs.
• Account for timing differences, aggregation, and data inconsistencies.
• Generate customized outputs that can drive reporting, exception handling, or accounting actions.
• Use exact and tolerant matching strategies.

Inputs

• Dataset A: Any dataset (e.g., bank transactions, ledger entries, PSP events, invoices, operational records) in any format
• Dataset B: One or more datasets reconciled against Dataset A

Datasets can contain transactional (e.g., payments) or non-transactional records (e.g., usage data), and can be matched based on any field that appears in both datasets. They can also be in any format – Reiterate OS is able to ingest and standardize any file format (i.e., .csv, .pdf, .html, Google Sheets, etc).

Matching steps

You can define the matching logic and steps. Once a record is matched, it's excluded from further matching steps.

1. Identifier-based matching

Matches records using a shared unique identifier, such as transaction IDs, invoice IDs, reference numbers or any other custom unique key.

This step prioritizes deterministic, one-to-one matches.

2. Exact value matching

Matches records based on exact equality across selected fields, such as amounts, dates, or currencies. Used for one-to-one matches when unique identifiers are not present.

3. Tolerance-based matching

Matches records using predefined tolerances to account for allowed differences, such as date ranges (e.g., +- N days) or allowed amount differences (e.g., differences that occur due to rounding).

4. Similarity-based matching

Matches records based on pattern recognition across text or categorical fields, including customer names, payment descriptions, or other fields. Used when identifiers differ but contextual information aligns.

5. Grouped and aggregate matching

Matches records across one-to-many or many-to-one relationships, such as:

• A single batch record matched to multiple detailed records.
• Aggregated totals matched to itemized entries

Grouping logic and aggregation rules are configurable.

Outputs

The node produces structured result sets for downstream workflow steps:

• Matched records: Records successfully linked across datasets.
• Partially matched or discrepant records: Linked records with field-level differences or tolerance-based matches.
• Unmatched records: Records with no corresponding match in the compared datasets.
• Match metadata: Match type, step applied, confidence score, and reconciliation status.

Typical use cases

• Bank and ledger reconciliation
• PSP and internal back-office matching
• Deposit, payout, or fee reconciliation
• Invoice and payment matching
• Inventory, usage, or operational data reconciliation