Important Reconciliation Concepts to Note
It’s worth investing some time to fully understand the following terms and their definition to make navigating and using the Recital Reconciliation module easier.Transaction Reconciliation
Reconciling transaction data between two or more data sources, e.g., to ascertain complete data capture or omissions| # | Term | Definition |
|---|---|---|
| 1 | Flow | The end to end reconciliation life cycle, typically involveing data ingestion, data normalization, matching, exception handling and reporting. You can set up multiple reconciliation flows on Recital to match your reconciliation flow. |
| 2 | Transactions Data | Records of actual financial events/transaction record from a data source (e.g., internal ledger) |
| 3 | Matching | The way a user (or the system) defines logic/rules for how transaction reconciliation should happen between two or more transaction data sources (e.g., bank statements, GL, switch, settlement reports). These rules can be based on one or more fields, e.g., transaction amount, RRN, STAN, account number, reference number, narration, dates, or custom identifiers.” Matching logic can be saved for later re-use by users or the system. |
| 4 | Transformations | The process of converting, cleaning, enriching, and restructuring financial data so that it becomes usable, consistent, standardized and reliable for applying matching, grouping, reporting and compliance. Common transformations include filtering irrelevant fields or rows, concatenating transaction/unique IDs, trimming spaces, left/right functions, and applying business rules. Transformation actions can be saved for later re-use by users or the system. |
| 5 | Runs | A single instance of performing defined matching and transformations against your data. Multiple runs can be performed on the same input data, with different transformation and matching. Applying the same transformation and matching rules on the same data would result in the same run output. |
| 6 | Saved Matching Rules | Reusable matching logic that are configured once, stored, and automatically applied across transaction reconciliation runs. They are important for consistency (same logic applied across daily runs), efficiency (users don’t need to rebuild rules for each new run), scalability (support multiple reconciliation types, e.g., bank vs ledger, payments vs disbursement) and auditability. |
| 7 | Saved Transformation Rules | Reusable transformation actions that are configured once, stored, and automatically applied across reconciliation runs. They are important for consistency, efficiency, scalability and auditability. |
| 8 | Versioning | Re-using aspects of a previous runs’ associated rules (matching or transformation) and data sources (matched or un-matched data) for a new run while ensuring consistency. A good use case for versioning is for performing incremental reconciliation where you ingest new data to try to reconcile un-matched data from a previous run, while re-using the un-matched data and rules from the previous version. |
Settlement Reconciliation
Reconciling transaction data between two or more data sources, e.g., to ascertain complete data capture or omissions| # | Term | Definition |
|---|---|---|
| 1 | Flow | The end to end reconciliation life cycle, typically involveing data ingestion, data normalization, matching, exception handling and reporting. You can set up multiple reconciliation flows on Recital to match your reconciliation flow. |
| 2 | Transactions Data | Records of actual financial events/transaction record from a data source (e.g., internal ledger) |
| 3 | Settlement Data | Records of lump sum settled amount for each settlement category (e.g., Agency Banking Cashout) and account type (e.g., Amount Payable, Issuer Fee Receivable) from a data source (typically a processor or switch). |
| 4 | Transformations | The process of converting, cleaning, enriching, and restructuring financial data so that it becomes usable, consistent, standardized and reliable for applying matching, grouping, reporting and compliance. Common transformations include filtering irrelevant fields or rows, concatenating transaction/unique IDs, trimming spaces, left/right functions, and applying business rules. Transformation actions can be saved for later re-use by users or the system. |
| 5 | Grouping | The Settlement reconciliation grouping is used to specify the logic to consistently and reliably group the transactions in the transaction file to determine the aggregate settlement amount that we expect to see or reconcile against in the settlement file. Common fields used include transaction category and dates (if both transaction and settlement files include data for multiple dates). Grouping logic can be saved for later re-use by users or the system. |
| 6 | Runs | A single instance of performing defined matching and transformations against your data. Multiple runs can be performed on the same input data, with different transformation and matching. Applying the same transformation and matching rules on the same data would result in the same run output. |
| 7 | Saved Grouping Rules | Reusable grouping logic that are configured once, stored, and automatically applied across transaction reconciliation runs. They are important for consistency (same logic applied across daily runs), efficiency (users don’t need to rebuild rules for each new run), scalability (support multiple reconciliation types, e.g., bank vs ledger, payments vs disbursement) and auditability. |
| 8 | Saved Transformation Rules | Reusable transformation actions that are configured once, stored, and automatically applied across reconciliation runs. They are important for consistency, efficiency, scalability and auditability. |
| 9 | Versioning | Re-using aspects of a previous runs’ associated rules (matching or transformation) and data sources (matched or un-matched data) for a new run while ensuring consistency. A good use case for versioning is for performing incremental reconciliation where you ingest new data to try to reconcile un-matched data from a previous run, while re-using the un-matched data and rules from the previous version. |
Run Outcome
The final status and results generated from a run, after applying rules to source data, showing expected vs. actual cash/asset movements, and obligations between parties.| # | Term | Definition |
|---|---|---|
| 1 | Status | Shows if a record from the source data is fully, partially, or un-reconciled. |
| 2 | Settlement Category | Category of settlement from the file (e.g., Agency Banking Cashout).” Matching logic can be saved for later re-use by users or the system. |
| 3 | Account Type | Type of account from the file (e.g. Amount Payable, Issuer Fee Receivable). |
| 4 | Total Amount | Total settlement amount for this category and account type. |
| 5 | Total Fee | Total settlement fee amount from the settlement file for this category and account type. |
| 6 | Transaction Date Range | Date or date range for transactions in this settlement record. |
| 7 | Net Settlement | Net value of settlement after offsets fees and adjustments. |
| 8 | Matched Amount | The portion of the settlement amount successfully matched to transactions. |
| 9 | Unmatched Amount | The portion of the settlement amount not yet matched to any transaction.. |