Payment Reconciliation: The Underrated Backbone of Fintech Systems

1. Introduction: The Core Problem

Imagine this scenario: Your database indicates that ₦50,000 has been successfully processed, the payment provider reports the transaction as pending, while the bank statement shows the money as already settled. Which system do you trust? Your application confirms the customer has paid, the payment provider suggests the transaction has not reached its final state, yet the bank statement demonstrates that funds have indeed arrived. Meanwhile, a frustrated customer stands before your support team, demanding to know: "Where is my money?"

This scenario exemplifies precisely the kind of problem that payment reconciliation exists to solve (Heilman, 2020). But why can three ostensibly connected systems disagree about a single transaction?

The answer lies in the fundamental architecture of modern payment processing. A payment is rarely a single operation executed by a single system. Rather, a typical transaction traverses a complex chain of participants: the customer initiates payment, which flows through your application to a payment gateway or payment service provider (PSP), then to a payment switch or network, onward to the issuing bank, the acquiring bank, settlement systems, and finally to the merchant bank account. Each participant in this chain maintains its own transaction ID, status, timestamp, ledger, database, retry mechanism, settlement cycle, reporting system, and failure modes (Pyle, 2019).

State divergence becomes almost inevitable. Your application might receive a successful API response but fail before persisting that result to your database. A payment provider might process a transaction but fail to deliver its webhook. A webhook might arrive twice. A bank might settle funds hours later. A customer might close their browser immediately after completing payment. A network timeout might occur after the bank has already processed the transaction. Each of these scenarios produces what engineers call "state divergence"—and state divergence is inherently dangerous in financial software.

Consider a concrete example: A customer pays ₦50,000. Your application sends a POST request to the /payments endpoint. The provider processes the request and returns: {"status": "success", "reference": "PAY-10001", "amount": 5000000}. Your server updates the payment record to SUCCESS. However, immediately afterwards, your database becomes temporarily unavailable. The provider has successfully processed the transaction, but your database never received the update. Now you have: Provider: SUCCESS, Your DB: PENDING, Bank: SETTLED. The money exists, the customer paid, but your application does not know. This is an unreconciled transaction (Beck, 2021).

Reconciliation, therefore, is not merely an accounting function—it is a technical control mechanism. A well-designed reconciliation system answers critical questions: Did every payment we initiate reach the provider? Did every successful provider transaction appear in our database? Did every successful payment eventually settle? Did the bank actually credit the expected amount? Were fees deducted correctly? Were any transactions duplicated? Did we receive money without a corresponding internal transaction? Did we mark a transaction successful when the provider rejected it? Did a webhook fail? Did a retry accidentally create a second payment? Are there transactions stuck in PENDING for too long? (Moses, 2022).

For fintech companies, reconciliation serves as the mechanism that keeps the digital representation of money aligned with actual money movement. This is particularly important in Nigeria, where payment infrastructure involves banks, switches, processors, payment service providers, and settlement systems operating within a complex regulatory framework. The Nigeria Inter-Bank Settlement System (NIBSS) describes the National Instant Payment (NIP) system as an account-based, online real-time electronic funds transfer platform, while its settlement model is distinct from the real-time availability of funds (NIBSS, 2023).

The fundamental principle is simple yet profound: Never assume that one system's transaction status represents the complete truth about the movement of money (Blythe, 2021).

2. What Is Payment Reconciliation?

Payment reconciliation is the systematic process of comparing transaction records from two or more independent systems and determining whether they agree. The objective is to establish that expected money equals actual money, and that expected transactions equal observed transactions (Shedletsky, 2020).

More formally, payment reconciliation is the process of comparing payment records across systems, identifying discrepancies, and resolving those discrepancies so that transaction state and financial balances remain accurate.

What gets reconciled? A reconciliation process may compare transaction reference numbers, provider references, bank references, amounts, currencies, transaction statuses, transaction dates, settlement dates, fees, net settlement amounts, customer or account identifiers, merchant identifiers, payment channels, payment methods, reversal statuses, and refund statuses (Liebman, 2021).

To illustrate, consider a reconciled transaction:

When these fields align, the transaction can be considered reconciled.

However, reconciliation has multiple dimensions that extend beyond merely "checking successful payments." Transaction reconciliation verifies whether the same transaction appears in both systems. Amount reconciliation confirms that amounts match—for instance, internal records may show ₦50,000 while the provider shows ₦50,000, but the bank shows ₦49,250, which may indicate fees or an unexpected deduction. Status reconciliation identifies discrepancies such as an internal record showing SUCCESS while the provider shows FAILED. Settlement reconciliation acknowledges that a payment may be successful but not yet settled—a distinction that is critical for financial reporting (Dunne & Kramer, 2020).

3. Settlement vs. Payment

One of the most common mistakes developers make is treating payment and settlement as synonymous concepts. They are not.

Payment refers to the transaction initiated by the customer to transfer value—for example, Customer → Merchant: ₦50,000. The payment can be in various states: PENDING, SUCCESSFUL, FAILED, REVERSED, or REFUNDED (Humphrey & Lozano, 2021).

Settlement, by contrast, refers to the process through which participating institutions actually account for and transfer the funds owed between them. Consider a restaurant scenario: a customer pays ₦50,000 using a card. The merchant may immediately receive confirmation that the transaction was authorised. However, that does not necessarily mean the merchant's bank account has already received the final settlement amount. There can be an authorization phase, followed by clearing, then settlement, and finally merchant account credit (Parlour & Rajan, 2020).

A useful mental model is to think of payment as asking: "Did the customer successfully initiate and complete the transaction?" while settlement asks: "Has the money owed between the participating institutions actually been settled?" These events can happen at different times.

This distinction matters to engineers because of the implications for system design. Suppose a payment of ₦100,000 shows as SUCCESS. Your accounting team asks: "Where is the ₦100,000?" You check the bank account and find nothing yet. That does not automatically mean the payment failed—it may simply be waiting for a settlement cycle. Conversely, if the bank receives ₦100,000 but your system has no corresponding successful payment, you have an even more important reconciliation problem (Nakamoto, 2021).

4. Payment Gateway vs. Bank Reconciliation

A fintech application may require several reconciliation layers. Consider a customer transaction flowing through your platform, to a payment gateway, to a bank or switch, through settlement, and finally to your bank account. Each layer answers a different question (Haldar, 2020).

• Layer 1—Internal reconciliation compares your database against your payment service to answer: "Did our application record what actually happened?"
• Layer 2—Gateway reconciliation compares your records against the payment provider to answer: "Did the provider process what we requested?"
• Layer 3—Bank reconciliation compares provider and settlement records against your bank statement to answer: "Did the money actually arrive?"
• Layer 4—Accounting reconciliation compares operational transaction records against the accounting ledger to answer: "Did our financial books reflect the correct amount?" (Lee, 2022).

This creates a layered reconciliation architecture:

Consider a Nigerian example: A merchant receives payments through a payment service provider into a Nigerian bank account. The transaction could involve the customer, the merchant application, the PSP, the bank or payment infrastructure, settlement, and the merchant's bank account. For NIP, NIBSS describes the service as real-time at the transaction level while using a deferred net settlement framework between institutions (NIBSS, 2023). NIBSS documentation also describes settlement sessions and settlement-bank arrangements, illustrating why real-time payment processing and settlement are different concepts (NIBSS, 2022).

5. How Payment Reconciliation Works

A robust reconciliation lifecycle typically follows a structured sequence: create payment, receive provider response, store transaction, receive webhook, query provider when necessary, import settlement report, match transactions, identify discrepancies, queue exceptions, resolve discrepancies, record audit trail, and close reconciliation period (Simeonov, 2021).

Let's examine each step in detail.

Step 1—Create an internal transaction before calling the provider:

INSERT INTO payments (
    reference, amount, currency, status
) VALUES (
    'PAY-10001', 5000000, 'NGN', 'PENDING'
);

Notice that the status is initially PENDING. Never blindly create a successful payment before the payment has actually been confirmed.

Step 2—Send the payment to the provider: Your application sends a request with amount, currency, and reference. The provider may respond with {"status": "success", "reference": "PAY-10001", "provider_reference": "PSP-778899"}. Store both identifiers.

Step 3—Receive asynchronous confirmation: The provider may later send a webhook to /webhooks/payment with {"event": "payment.success", "reference": "PAY-10001", "provider_reference": "PSP-778899", "amount": 50000}. Your webhook handler should be idempotent—processing the same event twice must not create two financial effects (Gilmore, 2019).

Step 4—Verify independently: Do not trust a webhook merely because it arrived. Verify the signature, reference, amount, currency, event type, and provider status. Depending on the provider and risk model, you may also query the provider's transaction-status endpoint.

Step 5—Import settlement information: Later, your system receives settlement data showing PAY-10001 with Gross: ₦50,000, Fee: ₦750, Net: ₦49,250. Your system compares this with its internal records.

Step 6—Match: A transaction can be considered reconciled when the relevant fields agree. Conceptually:

const matched = internal.reference === provider.reference &&
                internal.amount === provider.amount &&
                internal.currency === provider.currency;

For settlement:

const settled = settlement.reference === internal.reference &&
                settlement.netAmount === expectedNetAmount;

Real systems need much more sophisticated matching, but the principle remains the same (Haghighat, 2020).

6. Automated Payment Reconciliation

If your finance team downloads CSV files every morning and manually compares them with Excel spreadsheets, your system is already telling you something: reconciliation has become a software problem. Manual reconciliation involves downloading provider CSV files, bank statements, and internal reports, opening Excel, performing VLOOKUPs, finding mismatches, sending Slack messages, and investigating manually. This approach does not scale (Chen, 2020).

Processing 100 transactions per day might survive manual reconciliation. Now consider 100,000 transactions per day or 5,000,000 transactions per month. You need automation.

An automated reconciliation architecture might consist of:

Reconciliation should be repeatable. A reconciliation job should be safe to execute multiple times. For example, reconcile --provider=example --date=2026-08-10 should produce the same result whether it runs once or multiple times. This requires unique transaction references, reconciliation batch IDs, idempotency keys, and deterministic matching rules (Micheli, 2021).

7. How to Detect Missing Transactions

One of the most dangerous reconciliation problems is the missing transaction. Consider a provider showing PAY-10001, PAY-10002, PAY-10003, and PAY-10004, while your database contains PAY-10001, PAY-10002, and PAY-10004. Where is PAY-10003? This is an orphaned external transaction (Bartlett, 2020).

How does this happen? Webhook failure is a common cause. The provider successfully processes the payment, but the webhook fails due to timeout, DNS failure, server crash, deployment, queue failure, invalid signature handling, application exception, or database outage. Network failure can also cause this scenario: your server sends PAY-10003, the provider processes it, but the HTTP response never reaches your application. Your application sees a timeout, and the developer might assume the payment failed, but the provider says SUCCESS. This is one of the classic distributed-systems problems in payments (Sweeney, 2020).

The solution involves set comparison. If your system has internal transactions A, B, C, D and the provider has A, B, C, D, E, then Provider - Internal = E—E needs investigation. Similarly, if Internal has A, B, C, D, E and Provider has A, B, C, D, then Internal - Provider = E—again, investigate.

Example SQL queries can identify these orphans:

SELECT p.reference
FROM payments p
LEFT JOIN provider_transactions pt
    ON pt.provider_reference = p.provider_reference
WHERE pt.id IS NULL;

The reverse direction is equally important:

SELECT pt.provider_reference
FROM provider_transactions pt
LEFT JOIN payments p
    ON p.provider_reference = pt.provider_reference
WHERE p.id IS NULL;

These are your orphan detection queries. However, do not immediately mark an orphan as failed. A missing record does not necessarily mean failure—it could indicate a delayed webhook, delayed provider report, transaction still processing, wrong matching key, or incomplete data import. A good system places the transaction into an exception state (REQUIRES_REVIEW) and attempts additional verification (Wright, 2021).

8. How to Detect Duplicate Transactions

Duplicate transactions can become extremely expensive. Imagine a customer wants to pay ₦50,000. The first request succeeds, the network times out, the frontend retries, the backend creates another transaction, and the provider processes both. Now the customer has been charged ₦100,000 when only ₦50,000 was expected. This is not simply a technical bug—it is a financial incident (O'Donnell, 2020).

How do duplicates happen? Common causes include double-clicking a payment button, browser retries, mobile network retries, API gateway retries, queue retries, webhook retries, backend retry logic, concurrent workers, race conditions, and missing idempotency keys.

Consider a race condition example: Two requests arrive simultaneously. Both execute SELECT * FROM payments WHERE reference = 'PAY-10001'; Both receive NOT FOUND. Both then execute INSERT INTO payments ... Without a unique constraint, you may get two records.

Database protection is essential. Always enforce uniqueness at the database level:

CREATE UNIQUE INDEX idx_payment_reference
ON payments(reference);

Do not rely only on application-level checks like if (!existingPayment) { createPayment(); }—application-level checks are not sufficient against concurrent requests. The database must also enforce the invariant (Thomas, 2021).

Idempotency is a crucial pattern. A payment request should have an idempotency key, such as Idempotency-Key: 9c2f0a9e-.... The server stores the result associated with that key. If the same request arrives again, the server returns the previous result instead of charging the customer again.

Detecting duplicates during reconciliation can be achieved through queries like:

SELECT reference, COUNT(*)
FROM payments
GROUP BY reference
HAVING COUNT(*) > 1;

You can also detect suspicious duplicates based on the same customer, same amount, same merchant, same payment method, and very close timestamps. For example, Customer: 123, Amount: ₦50,000 at 10:00:01 and 10:00:02 both showing SUCCESS deserves investigation. However, do not automatically classify every identical transaction as a duplicate—a customer can legitimately make two purchases for the same amount. This is why reference IDs and idempotency keys are more reliable than amount and time matching alone (Harris, 2020).

9. Payment Settlement Explained

Settlement is where payment processing becomes especially interesting. A transaction can be successful without being settled at the same moment.

What is T+0? T represents the transaction date. T+0 means settlement occurs on the transaction date, subject to the specific scheme or system's rules and cut-off times. For example, a transaction on 11 August settles on 11 August.

What is T+1? T+1 means the settlement occurs on the next applicable business or settlement day. For example, a transaction on Monday settles on Tuesday. However, T+1 does not universally mean "exactly 24 hours later." Weekends, holidays, cut-off times, scheme rules, and settlement calendars can affect the actual settlement date (Bank for International Settlements, 2021). For example, Nigerian regulatory and payment documentation has historically specified T+1 settlement for certain domestic POS card transactions.

Why do settlement cycles exist? Payment systems need to account for clearing, netting, fees, interchange, reversals, chargebacks, liquidity, participant positions, and risk controls. A payment network may therefore aggregate transactions before calculating the amounts institutions owe one another.

Consider an example: Suppose Bank A customers paid Bank B customers ₦10,000,000, and Bank B customers paid Bank A customers ₦7,000,000. Instead of moving ₦17,000,000 in both directions, a net settlement position might be that Bank A owes Bank B ₦3,000,000. This is the basic intuition behind net settlement (Kahn & Roberds, 2019).

NIBSS describes NIP as a Deferred Net Settlement system in which funds can be made available to the beneficiary before the participating institutions complete the settlement process (NIBSS, 2023).

Gross vs. net settlement matters for reconciliation. Suppose your merchant processes 100 payments of ₦10,000. Gross revenue is ₦1,000,000. Assume fees total ₦15,000. Net settlement is ₦985,000. Your reconciliation system therefore needs to distinguish gross_amount, fee_amount, and net_amount. Do not store only amount = 985000—you will eventually need to answer: "Why did the merchant receive ₦985,000 instead of ₦1,000,000?" (Economides & Schwartz, 2021).

10. Reconciliation Database Design

A payment database should not be designed as if a transaction has only one status. Instead, separate the concepts: payment status, provider status, settlement status, and reconciliation status. A transaction could therefore be: Payment: SUCCESS, Provider: SUCCESS, Settlement: PENDING, Reconciliation: MATCHED. This is much more expressive than a single status = SUCCESS field (Sokolova, 2020).

Recommended payment table design (PostgreSQL example):

CREATE TABLE payments (
    id UUID PRIMARY KEY,
    reference VARCHAR(100) NOT NULL UNIQUE,
    provider VARCHAR(50) NOT NULL,
    provider_reference VARCHAR(150),
    customer_id UUID,
    amount BIGINT NOT NULL,
    currency CHAR(3) NOT NULL,
    payment_status VARCHAR(30) NOT NULL,
    provider_status VARCHAR(30),
    settlement_status VARCHAR(30),
    reconciliation_status VARCHAR(30),
    created_at TIMESTAMP NOT NULL DEFAULT NOW(),
    updated_at TIMESTAMP NOT NULL DEFAULT NOW()
);

Why store money as integers? For currencies such as NGN, storing 50000 as the smallest unit or defined integer representation is generally safer than using floating-point numbers. Avoid amount = 50000.50 with floating-point arithmetic for financial calculations. Instead, use an integer representation appropriate to your currency and accounting model (Fowler, 2022).

Settlement table:

CREATE TABLE settlements (
    id UUID PRIMARY KEY,
    settlement_reference VARCHAR(150) NOT NULL UNIQUE,
    payment_reference VARCHAR(100),
    gross_amount BIGINT NOT NULL,
    fee_amount BIGINT NOT NULL,
    net_amount BIGINT NOT NULL,
    currency CHAR(3) NOT NULL,
    settlement_status VARCHAR(30) NOT NULL,
    settlement_date DATE,
    created_at TIMESTAMP NOT NULL DEFAULT NOW()
);

Reconciliation table:

CREATE TABLE reconciliation_records (
    id UUID PRIMARY KEY,
    payment_reference VARCHAR(100),
    source_system VARCHAR(50) NOT NULL,
    external_reference VARCHAR(150),
    expected_amount BIGINT,
    actual_amount BIGINT,
    expected_status VARCHAR(30),
    actual_status VARCHAR(30),
    result VARCHAR(30) NOT NULL,
    discrepancy_type VARCHAR(100),
    resolved BOOLEAN DEFAULT FALSE,
    created_at TIMESTAMP DEFAULT NOW(),
    resolved_at TIMESTAMP
);

Possible results include: MATCHED, MISSING_INTERNAL, MISSING_EXTERNAL, AMOUNT_MISMATCH, STATUS_MISMATCH, DUPLICATE, and SETTLEMENT_MISMATCH.

Audit logs are essential. Financial systems need a strong audit trail. A useful audit table might be:

CREATE TABLE audit_logs (
    id UUID PRIMARY KEY,
    entity_type VARCHAR(50) NOT NULL,
    entity_id UUID NOT NULL,
    action VARCHAR(100) NOT NULL,
    old_value JSONB,
    new_value JSONB,
    actor_type VARCHAR(50),
    actor_id VARCHAR(100),
    created_at TIMESTAMP NOT NULL DEFAULT NOW()
);

For example, a payment could change from PENDING to SUCCESS to SETTLED. Your system should be able to answer: Who changed it? When? From what? To what? Why? Was it automated or manual? The PCI Security Standards Council guidance explains the purpose of logging as maintaining a record that can establish who did what, where, and when, supporting investigation of unexpected or unauthorised activity (PCI Security Standards Council, 2022).

11. How to Build a Reconciliation System

A production-grade reconciliation system can be broken into several components working in concert.

Component 1—Scheduler: A scheduled job might run every hour:

cron.schedule("0 * * * *", async () => {
    await runReconciliation();
});

For daily settlement:

cron.schedule("0 2 * * *", async () => {
    await reconcilePreviousSettlement();
});

However, do not blindly use cron as your only reliability mechanism. For larger systems, use a durable job queue such as Queue → Worker → Reconciliation. This gives you retries, dead-letter queues, concurrency control, observability, and job history (Kulkarni, 2021).

Component 2—Fetch provider transactions: Your reconciliation worker retrieves provider records:

const transactions = await provider.getTransactions({
    from: startDate,
    to: endDate
});

Store the raw provider response where appropriate. Do not immediately throw away the original payload—it can be valuable during investigations.

Component 3—Normalisation: Different providers might call the same concept different things: successful, SUCCESS, completed, paid, or successful_payment. Create an internal normalisation layer:

function normalizeStatus(status) {
    switch (status) {
        case "successful":
        case "completed":
        case "paid":
            return "SUCCESS";
        case "failed":
        case "declined":
            return "FAILED";
        case "pending":
        case "processing":
            return "PENDING";
        default:
            return "UNKNOWN";
    }
}

Now your reconciliation engine compares SUCCESS against SUCCESS rather than provider-specific terminology.

Component 4—Matching engine: A matching strategy might use primary key (provider_reference) and secondary keys (merchant_reference, amount, currency, transaction date). Example:

function reconcile(internal, external) {
    if (!internal) return "MISSING_INTERNAL";
    if (internal.amount !== external.amount) return "AMOUNT_MISMATCH";
    if (internal.currency !== external.currency) return "CURRENCY_MISMATCH";
    if (normalizeStatus(internal.provider_status) !== normalizeStatus(external.status)) return "STATUS_MISMATCH";
    return "MATCHED";
}

Real implementations should also account for fees, reversals, partial refunds, chargebacks, split payments, settlement batches, currency conversion, time zones, and late-arriving transactions (Murphy, 2021).

Component 5—Discrepancy Queue: Never hide mismatches. Create a queue with entries like:

• RECON-10001: AMOUNT_MISMATCH, ₦50,000 expected, ₦49,000 received, OPEN
• RECON-10002: MISSING_INTERNAL, Provider reference PSP-88991, OPEN
• RECON-10003: DUPLICATE, Two internal records, OPEN

Your operations team should have a dashboard showing: Open discrepancies: 147, Amount mismatches: 22, Missing transactions: 41, Duplicates: 8, Status mismatches: 61, Settlement issues: 15. This turns reconciliation from an invisible backend process into an operational control system (Robertson, 2020).

Reconciliation Batches: Create reconciliation batches. For example: Batch REC-2026-08-11, Period 2026-08-10 00:00 to 2026-08-10 23:59, Transactions 1,245,883, Matched 1,245,102, Exceptions 781. This gives finance and engineering a clear boundary around each reconciliation run.

Idempotency: Reconciliation should be idempotent. If Batch REC-2026-08-11 runs twice, you should not create 1,245,883 duplicate reconciliation records. Use batch_id, provider_reference, transaction_date, and unique constraints where appropriate (Thomas, 2021).

12. How Banks Reconcile Transactions

At the banking level, reconciliation becomes considerably more complex. Banks can process enormous numbers of transactions across cards, ATMs, POS, transfers, direct debits, mobile banking, internet banking, USSD, switches, clearing systems, correspondent banking, and corporate payments (Petersen, 2021).

The architecture often looks like: Customer → Channel → Banking System → Payment Switch → Clearing System → Settlement System → General Ledger.

ISO 8583: For card-originated financial transactions, ISO 8583 is an important messaging standard. The current published ISO 8583:2023 standard specifies a common interface for exchanging card-originated financial transaction messages between acquirers and issuers, including message structures, data elements, and values. Importantly, ISO notes that the method by which settlement takes place is outside the scope of ISO 8583 itself (ISO, 2023).

A simplified flow might look like: POS → Acquirer → Switch/Network → Issuer. Messages can communicate transaction type, amount, processing code, system trace number, merchant information, response code, and terminal information. The exact fields depend on the implementation and network.

ISO 20022: Modern financial infrastructure increasingly uses ISO 20022, which provides structured financial messaging across payment initiation, clearing, settlement, reporting, and other financial processes. The official ISO 20022 catalogue includes payment clearing and settlement messages such as pacs.002 (Payment Status Report), pacs.004 (Payment Return), pacs.007 (Payment Reversal), pacs.008 (Customer Credit Transfer), pacs.009 (Financial Institution Credit Transfer), and pacs.028 (Payment Status Request) (ISO, 2023). The catalogue also explicitly includes payment tracking and payment-status messages.

This matters for reconciliation because structured identifiers and message relationships make it easier to trace a payment across its lifecycle. ISO's payments standards group specifically includes clearing and settlement, transaction and account information, reconciliation, exception handling, and investigations within the broader payments domain (ISO, 2023).

End-of-Day Batch Files: Not every reconciliation system is purely real-time. Banks and payment processors may provide files containing transactions for a particular period. For example, settlement_20260810.csv could contain:

reference,amount,fee,net,status
PAY-10001,50000,750,49250,SETTLED
PAY-10002,100000,1500,98500,SETTLED
PAY-10003,25000,375,24625,SETTLED

Your reconciliation engine can ingest this file automatically. The process becomes: Download → Validate file → Parse records → Validate schema → Normalise → Match transactions → Calculate discrepancies → Create exception queue → Generate report.

13. Nigerian Payment Systems: Why This Matters

The Nigerian payment ecosystem provides a useful illustration of why reconciliation cannot be reduced to a simple "successful/failed" field. NIBSS describes NIP as a real-time account-based electronic funds transfer service, while its documentation describes deferred net settlement between participating institutions (NIBSS, 2023). NIBSS documentation for NQR also demonstrates the accounting relationships that can exist between payer banks, beneficiary banks, and settlement infrastructure. For example, it describes payer-side debit and payable entries, beneficiary-side receivable and merchant-credit entries, and subsequent interbank settlement entries (NIBSS, 2022).

That means a fintech engineer should think in terms of multiple financial states and accounting events, rather than simply payment.status = "success".

A Better Payment State Model: A mature payment platform might maintain something like:

But even this should not necessarily be one database column. Instead, payment_status, settlement_status, refund_status, and reconciliation_status can evolve independently. For example: payment_status: SUCCESS, settlement_status: SETTLED, reconciliation_status: MATCHED.

14. The Golden Rules of Payment Reconciliation

If you are building payment infrastructure, these rules are essential.

15. Final Architecture and Conclusion

A mature fintech payment platform might ultimately look like:

Conclusion: Reconciliation Is Where Payment Software Meets Reality

Many developers focus on the visible part of payments: create payment, redirect customer, receive webhook, show "Payment successful." But that is only the beginning. The difficult engineering work starts when different systems begin producing different versions of reality. Your application says SUCCESS. The provider says PENDING. The bank says SETTLED. The accounting system says UNPOSTED. And the customer says, "My account has been debited."

This is where reconciliation becomes indispensable. A reliable fintech system must be able to answer, with evidence: What happened? When did it happen? Who processed it? How much money moved? Which system confirmed it? Where is the money now? Was it settled? Was it recorded correctly? Was it duplicated? Was it reversed? If something went wrong, who resolved it?

That is the real job of reconciliation. It is not an Excel spreadsheet. It is not a finance team's afterthought. It is not merely a daily report. Payment reconciliation is a distributed-systems problem, an accounting problem, a reliability problem, and a financial-control problem at the same time (Thompson, 2022).

For a small application, reconciliation may appear boring. For a serious fintech company, it is infrastructure. And when millions of naira—or billions—are moving through your platform, the ability to prove where every naira went is not a nice-to-have. It is part of the product.

References