Why ledger reconciliation is harder when the ledger is self-hosted
Reconciliation is a control your team builds, staffs and evidences; it is not a feature you switch on when the ledger goes live. Once balances sit in a self-hosted ledger, someone must match those entries against bank statements and processor exports every day and again at month end, and the result must be explainable to an auditor. The ledger is the internal record, while the bank and processor files are external records with their own cut-off times, settlement batches and fee treatment. The gap between those records is where exceptions come from, and no ledger removes that gap on its own.
The timing differences are the first thing to design for. A card payment may be authorized in the ledger on one day, captured at the processor the next, and settled to the bank days later, with fees netted out of the payout. Your team must decide which event posts to the ledger, which file is the source of truth for each stage, and how a late or reversed item is treated. Blnk is the hub ledger in this design, and its reconciliation capabilities, including how it matches external records and holds unmatched items, must be confirmed against the exact version you deploy. Write down the matching keys, such as the processor transaction ID, the bank reference and the amount and currency, before you configure anything.
Self-hosting also moves ownership of the exception process to you. Someone must own the queue of unmatched items, set aging thresholds, approve manual adjustments as correcting entries rather than edits to history, and produce the month-end pack that ties ledger balances to statements. Ask your implementation partner to show how each unmatched item is recorded, who can clear it, and what evidence is kept when it is cleared. Confirm these roles and retention periods against your own control framework and any record-keeping rules that apply to you, because the reconciliation evidence is only as credible as the process that produced it.
Which control requirements shape the reconciliation design
This table maps the control requirements most likely to affect a self-hosted reconciliation service to where each one comes from and what it means for the build. Read each row as a design input to settle before the matching engine and exception queue are configured. The main takeaway is that encryption, access, logging and testing cadence apply to the reconciliation service and its feeds, not only to the ledger database.
| Requirement | Where it comes from | What it means for the build |
|---|---|---|
| Encryption of customer information | FTC Safeguards Rule, 16 CFR 314.4, for covered financial institutions | Encrypt bank statement files, processor exports and matched records in transit over external networks and at rest, including staging folders and report outputs. |
| Multi-factor authentication for system access | FTC Safeguards Rule, 16 CFR 314.4 | Require MFA for anyone who can view, approve or override exceptions, change matching rules or pull month-end reports, including vendor support accounts. |
| Change management for matching rules | FTC Safeguards Rule, 16 CFR 314.4 | Treat reconciliation rules, tolerance thresholds and posting mappings as controlled changes with review, approval and a rollback path. |
| Logging of authorized user activity | FTC Safeguards Rule, 16 CFR 314.4 | Log who uploaded a statement, who matched or cleared an item, who changed a rule and who exported a report, and keep those logs protected from the operators they record. |
| Penetration testing and vulnerability assessment cadence | FTC Safeguards Rule, 16 CFR 314.4(d)(2), absent effective continuous monitoring | Include the reconciliation service, its file ingestion endpoints and API connections to processors in the annual penetration test and at least six-monthly vulnerability assessments. |
| Retention of bank statements and bills receivable or payable | SEC Rule 17a-4(b), applies only to broker-dealers | Confirm whether the organization is a broker-dealer before adopting this rule. If it is, keep statements and bills for at least three years, with the first two easily accessible. |
| Matching completeness | Internal control goal, design requirement to confirm with the organization's auditor | Every bank line and processor record should be matched, queued as an exception or explicitly marked as out of scope, with counts that reconcile to source file totals each run. |
| Audit trail for matches and adjustments | Internal control goal, design requirement to confirm with the organization's auditor | Each match, manual clearance and correcting entry should keep the source record references, the reviewer, the timestamp and the reason, so a month-end balance can be traced back to its inputs. |
Which ledger and finance platforms fit a reconciliation build
A reconciliation build usually combines a system that records internal balances with systems that hold bank and processor evidence. The platforms below play different roles in that design, so the first decision is which one owns the internal record, which one holds the external records, and where matching and exceptions live.
Blnk as the hub ledger
Blnk is an open source ledger intended to sit between payment flows and downstream accounting, so it is the natural place to hold internal entries that reconciliation compares against external records. Confirm with the vendor which reconciliation rules, matching logic and exception handling the current release supports, and which versions receive fixes. Do not assume a matching feature exists until you have seen it working against your own bank and processor export samples.
TigerBeetle as the balance store
TigerBeetle is built as a ledger of record for high-volume balances and transfers, so it holds the authoritative internal movements but is not designed as a reporting layer. Reconciliation therefore reads from its data through an export or query layer that you build or adopt, and that layer must preserve transfer identifiers and timestamps. Ask the vendor how the data can be extracted for matching, and how that extract is tested against the ledger's own totals.
Odoo Community for bank matching
Odoo Community is published under LGPL v3 and includes accounting with bank statement import and reconciliation, which can serve as the general ledger side of a match. Enterprise adds hosting, version upgrades and Studio customization, so confirm which reconciliation features you need are present in Community before you commit. Verify the statement import formats your bank provides and how unmatched lines are presented to finance staff.
ERPNext for finance matching
ERPNext is a free and open source ERP built on the Frappe framework and licensed under GPL-3.0, with accounting and bank transaction records that can be matched against vouchers. Confirm the bank reconciliation tool, the matching rules it offers, and whether it handles multi-currency settlement lines that your processor sends. Test it with a sample month of statements before treating it as the matching engine for production.
Hyperswitch for processor records
Hyperswitch is an Apache-2.0 composable payments platform that connects to multiple processors and can be self-hosted, so it is a source of payment-side status, refunds and reporting for the processor side of the match. It does not replace the bank statement, so you still need the settlement files from each processor. Confirm which export formats and settlement reports it produces, and how fee and payout records map to ledger entries.
How timing differences and unmatched items are handled by situation
A timing difference occurs when a payment is recorded in the ledger on one date but settles at the bank or processor on another, for example when a payment settles after the daily cutoff or on a bank holiday. The entry is correct; the bank record simply lands in a later period. The treatment is to hold the item as an expected, time-bounded match candidate rather than to post an adjustment. Confirm with your Blnk configuration how the reconciliation rules define the date tolerance and how a late bank line is linked to the original ledger entry.
- Expected treatment: Keep the ledger entry as posted and mark the item as awaiting bank confirmation, with the expected settlement date recorded.
- Owner: The treasury or cash operations team owns the item, with finance reviewing anything still open at period end.
- What is recorded: The original transaction reference, the expected and actual settlement dates, and the matching rule that linked them once the bank line arrives.
- Evidence kept: The bank statement line, the cutoff calendar in use, and the rule version that produced the match.
- Confirm: The exact date tolerance and whether holiday calendars are configurable in your Blnk setup, because no default window should be assumed.
Check that the cutoff calendar used by the reconciliation matches the bank's published holiday schedule for each account.
Processors usually settle a batch of captured payments as one net amount after deducting fees, interchange and any reserve. The ledger, however, often records each payment gross. Reconciliation therefore has to split one bank credit into many ledger entries and explain the difference through fee entries. Treat the fee and netting breakdown as posted journal lines, not as a silent variance.
- Expected treatment: Match the net settlement to a set of gross ledger entries, with fees and reserves posted as separate lines that sum to the bank amount.
- Owner: Payments operations owns the batch match; the finance controller approves fee postings and any reserve movement.
- What is recorded: The processor batch identifier, each gross transaction, each fee line, and the net amount received.
- Evidence kept: The processor settlement report, the batch-to-bank line link, and the fee schedule version in force on the transaction dates.
- Confirm: Whether Blnk's reconciliation rules support one-to-many matching against a single bank line, and how an unexplained remainder is surfaced.
Verify that the sum of gross entries, fees and reserves equals the bank credit to the cent before the batch is closed.
Refunds and chargebacks change money that has already been recorded. In a double-entry ledger they should be posted as new correcting entries that reference the original transaction, so the history shows both the sale and its reversal. Overwriting or deleting the original entry removes the evidence auditors need and breaks reconciliation against processor reports that list each event separately.
- Expected treatment: Post a reversing or correcting entry linked to the original transaction, and match it to the processor's refund or dispute record when it settles.
- Owner: Operations opens and manages the case; finance approves the posting, and risk or disputes teams own outcome decisions.
- What is recorded: The original and correcting transaction IDs, the dispute or refund reason code, and the date each state changed.
- Evidence kept: The processor dispute record, the correcting entry, and the approval trail for any manual posting.
- Confirm: Whether your Blnk configuration can link a correcting entry to its parent and how provisional chargeback holds are represented.
Sample a few disputes each month to confirm that every outcome has a visible chain back to the original sale.
Bank and processor files are sometimes delivered twice, late, or not at all, and a re-sent file can make the same settlement appear to be a second deposit. Reconciliation should detect repeated file identifiers and content hashes before any matching runs, and it should flag a missing expected file rather than assume the day was empty.
- Expected treatment: Reject a duplicate file at ingestion and log the rejection; treat a missing file as an open exception for the day until the source confirms otherwise.
- Owner: The integration or platform operations team owns file ingestion; finance owns the decision to accept a late or replacement file.
- What is recorded: File name, source, received time, checksum, and the status of each run, including rejected duplicates.
- Evidence kept: The original file as received, the ingestion log, and the source's confirmation of any replacement.
- Confirm: How Blnk identifies duplicate imports and what happens to a re-sent statement that partly overlaps an earlier one.
Test the duplicate-handling path with a replayed file in a non-production environment before go-live.
Some items will not match on the first run, and a small number will stay open. The risk is not the open item itself but an item that ages silently. Define a review window for each exception type, escalate when it passes, and record each decision so the queue shows why an item was resolved, written off or left open. The thresholds should be set by finance and the auditors' expectations, not by a default in the software.
- Expected treatment: Route each unmatched item to a named queue by type, and escalate it to a senior owner when the agreed review window has passed.
- Owner: Each queue has a named owner; the financial controller reviews aged items at month end.
- What is recorded: Age, exception type, every action taken, the reason code for any resolution, and the approver.
- Evidence kept: The exception history, month-end aged listing, and the sign-off for write-offs or reclassifications.
- Confirm: The review windows you will adopt, and which report formats Blnk or your reporting layer produces for aged items.
Agree the thresholds with finance and internal audit in writing before the first month-end close.
Integration points between the ledger, banks and processors
Reconciliation depends on six components that exchange data with the ledger: two ingestion paths for external records, the query layer, the exception queue, the general ledger interface and the evidence store. Each one should run inside the organization's own cloud account, data center or air-gapped network, with access limited to the roles that need it.
Bank statement ingestion
This component receives statement files from each bank account and normalizes them into entries the matching rules can read. The formats each bank supplies vary, so confirm the file types, character encodings, cut-off times and delivery channel for every account with the bank before building parsers. Place the ingestion service in the same network zone as the ledger, with inbound transfers landing in a restricted staging store that only the ingestion service account can write to.
Processor export ingestion
Each payment processor provides its own settlement and payout exports, with different field names, fee breakdowns and refund treatment. Confirm the export format, delivery method and reporting schedule for every processor in use, since these determine how fees and chargebacks reach the ledger. Keep processor credentials in a secrets manager inside your environment, and restrict read access to the ingestion job rather than to individual staff.
Ledger API and query layer
Reconciliation reads balances and transaction histories from the ledger and posts correcting entries when a match reveals an error. Corrections should be new entries that reference the original, never edits to posted records, so the query layer should expose read endpoints broadly to reporting while limiting write access to a small set of service accounts. Run it inside your private network with mutual TLS between services, and confirm which operations Blnk exposes for reversals before you design the flow.
Exception queue and user roles
Unmatched items, timing differences and suspected duplicates sit in an exception queue until someone resolves them. Define roles that separate those who investigate, those who approve a correcting entry and those who close a period, so no one person can both create and clear an item. Host the queue in your network, require multi-factor authentication for every user who can see customer data, and log each action with the user identity.
General ledger interface
Month-end totals from the operational ledger must post into the general ledger in a form the accounting team can tie out. The interface should send summarized journal batches with control totals, and it should block posting for a period until reconciled balances match. Confirm the target system's import format and whether it accepts batch identifiers for traceability, and run the interface under a service account with change control over its mapping rules.
Evidence store and retention
Statements, match results, approval records and exports form the evidence that auditors and examiners request. Set retention periods from your own obligations: if you are a broker-dealer, SEC Rule 17a-4(b) sets a minimum of three years for bank statements and related records, with the first two in an easily accessible place. Store evidence in write-once or access-logged storage in your environment, and confirm the retention schedule with your compliance and legal teams before go-live.
How a reconciliation rollout moves from scope to month-end run
The sequence moves from an agreed inventory of accounts and files to a tested rule set, a supervised exception workflow, a parallel close and a documented cutover, so finance can rely on the self-hosted reconciliation before the old process is retired.
Inventory accounts, processors and file formats
DeployOpen works with your finance and operations leads to list every bank account, payment processor, settlement report and internal ledger account in scope. For each source, the inventory records the file format, delivery method, timezone, cutoff rule and who owns the export. The output is a signed scope document that states what is in and out of the reconciliation, so no feed is discovered mid-project. Done when finance confirms the inventory matches its close checklist.
Design matching rules and timing tolerances
Using the inventory, the team defines matching keys such as transaction ID, amount, currency, value date and reference, and sets the rules for timing differences, such as settlements that land a day after the ledger posting. Blnk's reconciliation features are configured against these rules only after you confirm they cover your case. Each rule is written down with its owner and the reason it exists. Done when the rule specification has been approved by the controller.
Test rules on historical files
The rules are run against several months of past bank statements and processor exports that finance has already reconciled by hand. Results are compared with the known outcome, and each mismatch is classified as a rule gap, a data format problem or a genuine exception. Test results, match rates and remaining unmatched items are documented in a test report. Done when every rule change is linked to a test result and the controller accepts the report.
Build the exception queue and access roles
Unmatched items flow into an exception queue with fields for age, source, amount, suggested cause and assigned owner. Roles separate who can view, who can investigate, who can approve a manual match or a correcting entry, and who administers the rules. Every action, including manual matches, reversals and approvals, is logged with user identity and timestamp. Done when a test user can complete a full exception lifecycle and the audit log shows each step.
Run in parallel through a full month-end close
The self-hosted reconciliation runs alongside the existing process for at least one complete close cycle, and the length of the run follows your own close calendar as set in the written scope. At close, DeployOpen produces a variance report comparing matched totals, unmatched items and differences against the legacy reconciliation, with each variance explained. Done when finance signs off on every variance or logs it as an open issue with an owner.
Cut over with runbook and retained evidence
Cutover follows a written runbook covering file feeds, scheduled jobs, rollback steps, contacts and the order in which the legacy process is switched off. The team retains the rule specification, test report, variance report, access matrix and audit log in a location your records policy covers. Done when the runbook has been rehearsed, the controller approves go-live, and the evidence package is filed with the close records.
Which evidence a reviewer asks for and which component produces it
This table maps each piece of evidence a reviewer typically requests for a reconciled self-hosted ledger to the system component that generates it. Read it as a checklist to design logging and retention before the first month-end close, not after an assessor asks. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any opinion on it.
| Evidence item | What it shows | Component that produces it |
|---|---|---|
| Matching completeness report | Every bank statement line and processor record is matched, unmatched or explained for the period | Reconciliation engine output reconciled against bank and processor export totals |
| Exception queue history | Each unmatched item, when it was raised, who owns it and how it was resolved | Exception queue with owner assignment and resolution workflow |
| Correcting-entry log | Each reversal or adjustment posted to fix a mismatch, with the reason and approver | Ledger posting history using correcting entries rather than edits to original transactions |
| Logged user actions in the reconciliation tool | Who viewed, matched, overrode or closed items, and when, supporting the activity logging expected under 16 CFR 314.4 | Application audit log and centralized log store with access restricted to authorized staff |
| Change records for matching rules | Which matching rules changed, who approved the change, and the test evidence before release | Version control for rule definitions, change tickets and staging test results |
| Penetration test and vulnerability assessment results | Testing of the reconciliation service at the frequency the Safeguards Rule sets when continuous monitoring is absent | Scheduled external test reports and remediation tracking for the reconciliation service |
| Retained statements and business communications | Bank statements and related records kept for the retention period that applies to the institution, confirmed with counsel | Document archive with retention rules, legal hold and access logs, such as the records preservation controls in 17 CFR 240.17a-4 where broker-dealer rules apply |
What buyers ask before hiring a partner to build reconciliation
How much effort does a reconciliation build take?
Effort depends mostly on how many bank and processor sources feed the ledger, how varied their file formats are, how complex the matching rules must be, how many items each close cycle produces, and how far the current close process is documented. A single bank account with one processor and a clean daily export is a small, bounded task. Multiple currencies, split settlements, partial refunds and chargebacks that post days later add rule design and test cases quickly. Ask any partner to break the estimate into source onboarding, rule design, exception handling, reporting and testing, so you can see which line items your own data will move.
How long does a reconciliation project usually run?
The timeline is set by the written scope, the number of sources, the length of the parallel run against your existing close, and how quickly the organization grants access to bank and processor exports and a test environment. No fixed duration applies across engagements. Parallel running deserves particular attention, because the new matching results should be compared with the manual close for enough cycles to show that differences are explained. Ask the partner to state which milestones depend on your team, such as rule sign-off and access approvals, and which depend on their work.
What does our finance team need to provide during the build?
Reconciliation rules are only as good as the finance knowledge behind them, so the organization needs named owners who can explain how each bank and processor settles, how timing differences are normally cleared, and which unmatched items are acceptable. Owners also need to supply sample statements and processor exports in their real formats, read-only access to the sources, a test environment that mirrors production data handling, and named approvers who sign off rule changes and month-end reports. Confirm these commitments in the written scope before work starts.
Can our own team build a reconciliation without a partner?
Yes, for simple matching against a small number of sources, provided the team has the right skills. Those skills include relational database design, scripting for file parsing and scheduled jobs, a working knowledge of double-entry accounting and settlement timing, and enough secure engineering practice to handle financial data. The harder parts are exception queue design, audit trails for every manual decision, and testing that proves the logic behaves correctly after each change. If these gaps exist internally, an outside partner can cover them in a defined scope while your team keeps ownership of the rules.
What work continues after go-live?
Reconciliation needs ongoing work after launch. Typical recurring tasks include adjusting matching rules when a bank or processor changes its file format or settlement pattern, onboarding new processors, applying platform and dependency upgrades, reviewing the exception queue trends, and keeping month-end reports aligned with finance requirements. These can be handled by your internal team or by a support retainer with a partner. Ask which tasks a retainer covers, how change requests are scoped and approved, and how upgrades are tested before they reach production.
Does reconciliation alone satisfy a regulator?
No. Reconciliation is one control within a wider body of evidence, and it does not by itself demonstrate compliance with any regulation. Regulators and auditors also look at access controls, logging of administrator activity, change management for posting logic, encryption, backup and recovery, and records retention. For example, the FTC Safeguards Rule at 16 CFR 314.4 covers encryption, multi-factor authentication, change management and activity logging for covered institutions, and the SEC's Rule 17a-4(b) sets retention periods for bank statements and related records for broker-dealers. Reconciliation outputs can support those controls, but your compliance team must decide which evidence applies to your entity. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors issue any opinion.
How is the cost of a reconciliation build quoted?
DeployOpen does not publish a price list. Most engagements are fixed-scope, so a written proposal follows from an agreed scope, deliverables and timeline. When comparing quotes from any partner, ask for each component to be priced separately: discovery and rule design, source connector work, exception queue and reporting, testing and parallel run support, documentation, handover, and any recurring retainer. Also ask which costs are one-time and which recur, such as hosting, licenses for the chosen platform, and support. Be wary of quotes that do not list what is excluded.
What to ask an implementation partner about reconciliation scope
Start by asking for a written scope that lists every bank account, payment processor, file type and month-end report included. Reconciliation projects fail most often at the edges: a processor's settlement file that was never mapped, a second bank account that finance assumed was covered, or a report nobody agreed to build. Ask the partner which bank statement formats and processor exports they have handled before, whether they can show sample files with the fields they parsed, and how they test those parsers with malformed rows, duplicated lines, currency changes and files that arrive late. Ask whether timing differences such as settlement lag, weekend cut-offs and partial refunds are handled by matching rules that are tested against several months of historical data, and whether they will report match rates and unmatched counts from that backtest before go-live.
Next, ask how exceptions are owned and approved. Your partner should describe the exception queue states, who may assign or close an item, how a reviewer's decision is recorded, and whether each action is logged with user identity and timestamp. Ask how correcting entries stay separate from edits to posted entries: a reconciling adjustment should be a new, linked transaction with its own approval, never an overwrite of a posted record. Also ask how they will run a parallel close, meaning the ledger and the existing close process produce month-end figures side by side for at least one full cycle, and what differences they will explain line by line before cutover.
Finally, ask what evidence they will hand over. The FTC Safeguards Rule at 16 CFR 314.4 expects change management procedures and activity logging for authorized users, and penetration testing or vulnerability assessments at least every six months where continuous monitoring is not in place. Confirm whether the partner will prepare change records for matching-rule updates, access reviews for reconciliation operators, and the penetration test scope covering the reconciliation service and its file ingestion endpoints. Ask which of these deliverables are fixed in the written scope and which would be billed as additional work.
How DeployOpen scopes and supports a reconciliation build
DeployOpen plans, implements, customizes, integrates, tests, documents and supports self-hosted open-source platforms inside your own infrastructure. For reconciliation, we start from the matching rules, exception ownership and month-end reports your finance team needs, then build and hand them over as a documented system.
How we scope
- Written scope lists each bank account, processor export and ledger account the reconciliation covers
- Scope names matching rules, tolerance thresholds and the timing windows used for late settlements
- Exception queue roles, escalation paths and who approves manual resolutions are defined before build starts
- Month-end reports, their recipients and their formats are agreed and listed as deliverables
- Engagements are fixed-scope, with timelines and deliverables confirmed in writing before work begins
How we build
- Matching rules are configured and tested against sample bank statements and processor exports you provide
- Timing differences such as in-transit settlements and reversals are tested with known edge cases
- Unmatched items route into the exception queue with the source record and ledger entry attached
- Access controls, logging of manual adjustments and change management for matching logic are implemented in your environment
- Integrations with bank feeds and processor exports are built inside your cloud accounts, data centers or air-gapped network
How we hand over
- Runbooks cover rule changes, queue handling, month-end close steps and recovery from a failed import
- Test evidence records which sample files, rules and expected results were used and what passed
- Configuration, interfaces and data flows are documented so your team can maintain them independently
- Walkthroughs with finance and operations staff cover the exception queue and report outputs
- Evidence packs are organized for your compliance team and independent auditors, who issue any assessment
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Upgrades of the ledger and reconciliation components are planned, tested and documented before release to production
- Security testing of the reconciliation interfaces can be scheduled as part of the same support relationship
- Changes to matching rules go through the same review and test steps used during the original build
- Support terms, response expectations and included services are set out in the written agreement
