SQL · Find the facts
The question
Which open invoices match this currency, account and permitted amount range?
Apply the matching rules.
Explore SQLFinancial services & payments
Resolve unmatched
payments.
Match payments to invoices using transaction details, remittance messages and settlement records. Show operators which references match and which differences need checking.
Payment reconciliation
Compare a payment reference with the invoice it may settle.
Illustrative use case01 / Use case guide
10 practical use cases.
Compare the data models behind everyday industry tasks, from finding records to following connections.
SQL Filter and calculate Vector Match similar meaning Graph Follow relationships Full-text Find words and phrases
Suggested model combination
Scroll across to compare all four models| Use case | How the data models help | SQL | Vector | Graph | Full-text | Source |
|---|---|---|---|---|---|---|
| Payment to invoice matching Operations teams need candidates for payments with incomplete remittance references. | SQL checks amounts and currencies, Full-text finds invoice references, and Vector suggests similar invoice descriptions for operator review. | SQL included | Vector included | Graph not needed for this example | Full-text included | |
| Cross border payment tracing Support teams need to locate a delayed payment along its processing route. | SQL retrieves timestamped payment statuses, while Graph follows linked intermediary and beneficiary events. | SQL included | Vector not needed for this example | Graph included | Full-text not needed for this example | |
| Merchant payout batch reconciliation Finance teams need to explain the difference between sales totals and bank payouts. | SQL totals charges, fees and adjustments, while Graph traces each payout to its recorded settlement transactions. | SQL included | Vector not needed for this example | Graph included | Full-text not needed for this example | |
| Card dispute evidence gathering Dispute teams need relevant receipts, delivery records and customer correspondence. | SQL selects the dispute and deadline, Graph links order and delivery evidence, and Full-text finds relevant customer messages. | SQL included | Vector not needed for this example | Graph included | Full-text included | |
| Missing refund status investigation Support teams need trace references for a refund that a customer cannot see. | SQL retrieves refund status and network references, while Full-text finds those references in support correspondence. | SQL included | Vector not needed for this example | Graph not needed for this example | Full-text included | |
| Payment decline pattern analysis Operations teams need to distinguish issuer declines from blocked payments and integration errors. | SQL groups failure codes and excludes repeat attempts, while Vector finds similar incident descriptions for troubleshooting. | SQL included | Vector included | Graph not needed for this example | Full-text not needed for this example | |
| Merchant onboarding document review Onboarding teams need to resolve inconsistent business, identity and payout details. | SQL checks verification status, Graph connects merchant entities and documents, and Full-text finds names in submitted evidence. | SQL included | Vector not needed for this example | Graph included | Full-text included | |
| Subscription payment failure review Billing teams need to understand which failed invoices still need customer follow-up. | SQL selects unpaid invoices and retry history, while Graph traces subscriptions to their configured payment methods. | SQL included | Vector not needed for this example | Graph included | Full-text not needed for this example | |
| Beneficiary payment detail checks Operators need to resolve account and routing discrepancies before resubmitting a payment. | SQL compares stored payment fields with validation results, while Full-text retrieves the original beneficiary instructions. | SQL included | Vector not needed for this example | Graph not needed for this example | Full-text included | |
| Payment screening exception review Compliance teams need the message context behind a flagged payment. | SQL retrieves the payment and screening result, while Full-text locates party names and remittance wording for analyst review. | SQL included | Vector not needed for this example | Graph not needed for this example | Full-text included |
Use the query interfaces you need, then connect their results through shared record IDs in your application.
Industry sources 10
These sources describe real industry workflows. The model combinations above are proposed OriginChainDB designs, not customer deployment claims.
- Scotiabank — The new language of payments: structured remittance and reconciliation (opens in a new tab)
- Swift — Closing the case on payment investigations (opens in a new tab)
- Stripe — Payout reconciliation report (opens in a new tab)
- Stripe — Respond to disputes (opens in a new tab)
- Stripe — How to trace a refund using reference numbers (opens in a new tab)
- Stripe — Payment declines and failure analysis (opens in a new tab)
- Adyen — Onboarding guidelines and verification issues (opens in a new tab)
- Stripe — Failed subscription and invoice payment retries (opens in a new tab)
- Swift — Payment Pre-validation: beneficiary account verification (opens in a new tab)
- Swift — Transaction Screening (opens in a new tab)
02 / A closer look
A payment arrives without a usable invoice reference
A payment reaches the bank but cannot be matched confidently to an invoice. A reference is incomplete, fees change the amount, and the remittance explanation lives in a message. Operations must distinguish a valid match from a coincidence.
What makes it difficult
- 01
Payment, invoice and settlement identifiers do not always align.
- 02
Amounts differ because of fees, partial payments or currency conversion.
- 03
An exception needs an explanation, not just a suggested match.
Suggested approach
Exact matching first
Match references, currencies and amounts using approved rules. For unresolved payments, search remittance wording for possible invoices and send the candidates to an operator.
03 / Queries
What each data model does
Select a model to see the question it answers.
Vector · Match the meaning
The question
Which invoice descriptions resemble this remittance explanation?
Suggest a candidate from wording.
Explore Vector Graph · Follow the connections
The question
Which invoice, batch and settlement events connect to this payment?
Trace the payment lifecycle.
Explore Graph Full-text · Find the exact wording
The question
Which remittance messages contain this invoice number?
Locate exact message references.
Explore Full-textUse shared record IDs to combine results from the different query interfaces in your application.
04 / Implementation
How to build it
- STEP 01
Define matching rules
Choose one payment rail. Set currency and amount tolerances, and decide which exceptions require an operator. Use masked historical records.
- STEP 02
Preserve payment references
Link payment, invoice and settlement IDs. Keep original messages, timestamps and corrected versions. Index the remittance text.
- STEP 03
Show candidate matches
Run exact checks first. Search descriptions for unresolved payments. Your application ranks candidates and shows the references and differences behind each suggestion.
- STEP 04
Check known exceptions
Compare with approved matches. Include duplicate payments, reversals and partial payments. Measure false matches before introducing assisted review.
05 / Testing
What to measure
Compare these results with your current process before rollout.
False matches
Track suggestions that operators reject, especially wrong-counterparty and duplicate matches.
Exception resolution time
Compare time to gather evidence and resolve equivalent exception categories.
Record freshness
Measure delay between settlement updates and their appearance in the review workspace.
06 / Sources
Examples from the industry
Published projects and reference material relevant to this use case.
Scotiabank
Structured payment data for reconciliation
Scotiabank describes embedding ISO 20022 into its systems and using richer remittance information to support payment-to-invoice reconciliation. This is Scotiabank’s own industry example, not an OriginChainDB customer story.
Read the sourceSwift
ISO 20022 for financial institutions
Swift explains how richer payment information can support reconciliation and reduce manual correction and investigation. Adopting a message standard still leaves downstream systems responsible for using that information effectively.
Read the sourceThese are industry references, not OriginChainDB customer stories. The implementation above is a proposed example.
Build with OriginChainDB