From a payment-system perspective, that is incomplete.

A payment can move through several different states before the business can confidently match it to an invoice and a bank deposit. The transaction created at checkout may not contain everything needed for reconciliation later.

This makes reconciliation partly a data architecture problem.

A well-designed payment system needs to preserve the relationship between the original transaction, subsequent payment events, settlement information, and the business record the payment was intended to satisfy.

A Payment Transaction Does Not End When the Customer Pays

Consider a customer paying a $2,500 invoice.

The initial transaction might record:

Transaction ID: TXN-84721
Invoice: INV-1048
Amount: $2,500
Status: Processing

That is useful, but it is not yet a complete financial record.

Later, the payment system may receive additional events:

Payment initiated
Payment submitted
Payment processed
Payment settled
Settlement deposited

Or something may go wrong:

Payment initiated
Payment submitted
Payment returned

A reconciliation system needs to understand these events as parts of the same payment lifecycle, rather than treating each event as a separate transaction.

This distinction becomes especially important when payment processing and accounting systems are maintained separately.

The Transaction ID Should Follow the Payment Lifecycle

One common design mistake is creating different identifiers for different stages without preserving their relationship.

For example:

Checkout ID
     ↓
Processor ID
     ↓
Settlement ID
     ↓
Bank Deposit ID
     ↓
Accounting Entry

If these identifiers cannot be connected, reconciliation becomes dependent on manual matching.

A better design maintains a persistent internal payment identifier:

Payment ID
 ├── Invoice ID
 ├── Customer ID
 ├── Processor Transaction ID
 ├── Payment Method
 ├── Payment Events
 ├── Settlement Reference
 └── Accounting Reference

The processor's transaction ID can still be stored, but the business's internal payment ID becomes the anchor for the complete lifecycle.

Why this matters

When a merchant asks:

"Which invoice does this bank deposit belong to?"

the system should be able to trace the answer through stored relationships rather than searching through unrelated transaction records.

Payment Status and Settlement Status Are Different

Another common source of reconciliation errors is treating payment status and settlement status as the same thing.

They are not necessarily the same.

For example:

A payment can therefore be completed from a transaction perspective without being reconciled in the accounting system.

That distinction should exist in the data model.

Don't Build Reconciliation Around a Single Status Field

A database structure such as:

status = "paid"

is usually insufficient for a mature payment workflow.

The system may need separate fields for:

payment_status
settlement_status
reconciliation_status
refund_status
return_status

For example:

payment_status       = completed
settlement_status    = settled
reconciliation_status = matched
refund_status        = none
return_status        = none

This allows different systems to update the part of the lifecycle they actually control.

It also reduces the risk of one system overwriting information generated by another.

Webhooks Should Be Treated as Events, Not Final Truth

Payment APIs frequently use webhooks to communicate status changes.

A simplified sequence might look like:

Payment API
     ↓
payment.processing
     ↓
payment.completed
     ↓
settlement.created
     ↓
settlement.completed

The application should not assume that a webhook will arrive exactly once.

Network problems, retries, application failures, and provider behavior can result in duplicate event delivery.

That makes idempotency important.

For example, if the same event arrives twice:

event_id = EVT-73921

the application should recognize that the event has already been processed.

It should not create:

Settlement record #1
Settlement record #2

from the same event.

A practical event table might contain:

event_id
payment_id
event_type
received_at
processed_at
processing_status

The event_id should normally have a uniqueness constraint so the application can safely handle retries.

Reconciliation Needs an Exception Queue

Perfect matching is not realistic in every payment environment.

A useful reconciliation system should therefore identify exceptions instead of silently forcing records to match.

Examples include:

• Payment exists but no invoice is found

• Invoice exists but no payment is received

• Payment amount differs from invoice amount

• One payment covers multiple invoices

• Multiple payments relate to one invoice

• Settlement amount differs from expected amount

• Payment was returned after being marked completed

• Refund was issued but accounting has not recorded it

• Bank deposit cannot be linked to a settlement record

These records should enter an exception queue.

That gives finance and operations teams a specific list of records requiring review instead of asking them to manually inspect every payment.

Partial Payments Make Reconciliation More Interesting

Suppose an invoice is worth $5,000.

The customer pays:

Payment 1 = $2,000
Payment 2 = $1,500
Payment 3 = $1,500

The invoice should not simply store one payment ID.

Instead:

Invoice INV-5001
        |
        ├── Payment A: $2,000
        ├── Payment B: $1,500
        └── Payment C: $1,500

The system can then calculate:

Invoice amount:      $5,000
Amount received:     $5,000
Outstanding balance: $0

This model also handles invoices that remain partially unpaid.

Payment Method Should Be Part of the Reconciliation Model

The reconciliation workflow should not assume that every payment method behaves identically.

A card transaction, bank-based payment, and other payment methods can have different processing, settlement, return, and timing characteristics.

For example:

payment_method
    ├── card
    ├── eCheck
    ├── ACH
    └── other

The core reconciliation architecture can remain the same while payment-method-specific events are handled separately.

For an eCheck transaction, for example, the system may need to preserve information relating to the payment submission, processing status, return status, settlement, and eventual invoice matching.

That is why payment-method abstraction is useful at the application layer.

A Simple Data Model

A practical payment system could separate its data into several related entities:

Customer
   │
   └── Invoice
          │
          └── Payment
                 │
                 ├── Payment Events
                 │
                 ├── Settlement
                 │
                 ├── Return
                 │
                 └── Refund

This structure prevents the payment table from becoming a single record containing every possible state and event.

It also makes historical auditing easier.

For example, instead of changing:

status = returned

and losing the previous state, the system can preserve an event history:

09:01  payment.created
09:02  payment.submitted
09:08  payment.completed
+1 day payment.returned

The current status can then be derived from the latest valid state while the historical events remain available.

What a Reconciliation Dashboard Should Show

A useful dashboard should answer operational questions quickly.

For each payment, an operator should be able to see:

Business record

• Customer

• Invoice

• Invoice amount

Payment

• Payment ID

• Payment method

• Transaction amount

• Current payment status

Processing

• Processor transaction ID

• Processing events

• Return information, when applicable

Settlement

• Settlement reference

• Settlement date

• Settlement amount

Reconciliation

• Matched / unmatched

• Exception reason

• Last reconciliation attempt

The objective is not to show more fields.

It is to make the relationship between the fields obvious.

Where Payment Platforms Fit

Payment platforms can provide the transaction and processing layer, but merchants still need a clear internal relationship between payment records and business records.

For example, a merchant using an eCheck processing platform may generate an electronic payment against an invoice while also using invoicing, virtual terminal, or recurring-payment functionality.

The important architectural question is not simply whether the payment was accepted.

It is:

Can the business trace that payment from the original invoice through processing, settlement, and reconciliation?

That is the point where payment infrastructure and accounting data meet.

A Practical Reconciliation Checklist

Before implementing or reviewing a payment integration, check whether the system can answer these questions:

• Does every payment have a permanent internal ID?

• Can the payment be connected to an invoice?

• Are processor transaction IDs stored?

• Are payment events preserved?

• Can duplicate webhooks be safely processed?

• Are payment and settlement statuses separated?

• Can partial payments be represented?

• Can one payment be allocated across multiple invoices?

• Are refunds and returns represented independently?

• Can settlement records be linked back to individual payments?

• Does the system identify unmatched records?

• Is there an exception workflow?

• Can historical payment events be audited?

If several answers are no, reconciliation problems will eventually become an operational issue.

The Practical Takeaway

Payment reconciliation should not be designed as a spreadsheet exercise that happens after payment processing.

It should be considered part of the payment system's data architecture.

The strongest implementations preserve relationships between customers, invoices, payments, events, settlements, returns, refunds, and accounting records throughout the payment lifecycle.

That approach gives both engineering and finance teams the same underlying history.

And when something does not match, the system can identify what is missing and where the mismatch occurred, rather than simply showing that the numbers are different.