Payments Training Hub

Capstone Projects › Payment Reconciliation

Payment Reconciliation

Match every clearing record to the ledger, find breaks fast and resolve them cleanly

This project builds payment reconciliation that matches every clearing record to the ledger, identifies breaks quickly and resolves them before they affect customers or financial reporting. A 10,000 dollar SWIFT payment, a 500 euro SEPA credit transfer and a 2,000 pound Faster Payments transfer must each match to the correct ledger entry, with fees, FX and value dates handled correctly. The business analyst defines the matching rules, the tolerance for charges and FX differences, the exception workflows for missing, duplicate and partial matches, and the reports that finance and operations use to track breaks. The project covers file receipt, auto matching, case management, suspense accounting and daily, weekly and monthly reconciliation reporting. It also covers suspense accounting, write off approval and audit trails that prove each break was investigated and resolved on time.

Phases

Discovery and Current State Analysis

Matching Rules Design

Requirements and Workflow Design

Build Support

Testing and Validation

Go Live and Stabilisation

Deliverables

BRD

The Business Requirements Document states what the business needs from payment reconciliation, including the payment types, accounts, ledgers and clearing systems in scope. It covers receipt of clearing files and ledger records, matching rules, break identification, exception workflows and reporting. It defines the business rules for tolerance, value dating, charges and suspense accounting, and it is signed off by finance, operations and technology before design starts.

Template sections:

FSD

The Functional Specification Document describes how the reconciliation system must behave, from file ingestion and data validation through matching, break creation, exception workflow and reporting. It defines the matching rules for amount, currency, value date and reference, the tolerance for fees and FX, and the behaviour for partial matches, duplicates and missing records. Developers and testers use it as the precise specification for build and test.

Template sections:

Process Flow

The Process Flow shows the end to end reconciliation journey, from receipt of the clearing file to matched records, breaks, investigation and resolution. It uses swimlanes for finance, operations and technology, shows decision points for auto match, manual match and write off, and identifies the systems and people responsible at each step. Finance teams use it to understand the new process and to train staff.

Template sections:

Solution Architecture

The Solution Architecture describes the technology design for reconciliation, including file ingestion, the matching engine, the case management system, the data warehouse and the reporting layer. It shows how the system connects to clearing systems, the core banking ledger, the payment hub and the general ledger, and how it handles large volumes, data retention and audit. It guides developers and infrastructure teams during build.

Template sections:

Data Mapping Sheet

The Data Mapping Sheet lists every field that flows into reconciliation, from the clearing file, the ledger and the payment hub. It shows the source, the target, the data type, the transformation rule and the validation rule for each field, including transaction reference, amount, currency, value date, charges and status. It is the reference that developers and testers use to build and verify every interface and matching rule.

Template sections:

API Specification

The API Specification defines the interfaces for reconciliation file upload, break retrieval, case updates and reporting. It lists each endpoint, the request and response payloads, the authentication method, the error codes and the service levels for response time and availability. It lets operations, finance and audit teams access reconciliation data and update cases through a stable, secure contract. It also covers bulk upload, status polling and secure access for finance, operations and audit teams.

Template sections:

Jira User Stories

Jira User Stories break the reconciliation build into small, deliverable pieces that a development team can complete in a sprint. Each story states the user need, the business value and the acceptance criteria, and it is linked to the BRD, the FSD and the data mapping sheet. Stories cover file ingestion, matching, break workflow, reporting and dashboards, with clear priorities, dependencies and a definition of done.

Template sections:

Acceptance Criteria

Acceptance Criteria define the conditions that must be met before a reconciliation feature or release is accepted by the business. Each criterion is specific, measurable and testable, and it states the expected result for a given file or break, including matching accuracy, break creation, workflow routing and reporting. Criteria are agreed before development starts and are used as the basis for user acceptance testing and sign off.

Template sections:

UAT Scenarios

UAT Scenarios describe the business tests that prove reconciliation works end to end, from a 10,000 dollar SWIFT payment matched to the ledger to a 500 euro SEPA payment with a fee difference and a missing clearing record. Each scenario states the precondition, the test steps, the input, the expected output and the evidence required. Scenarios cover auto match, partial match, duplicate, missing record and write off cases.

Template sections:

RTM

The Requirements Traceability Matrix links every reconciliation requirement in the BRD to its functional specification, its design component, its user story, its test case and its UAT result. It shows which requirements are covered, which are in progress and which have failed testing, so that no requirement is lost during the build. It is the main evidence that the system meets the agreed scope and is ready for production release.

Template sections:

← Back to all capstones Download brief (p4.md)