The source documents describe the current business rules and technical implementation for Card Reconciliation and Interbank Reconciliation, with a common future-state theme: preserve proven matching behaviour while moving to configurable, provider/bank-neutral Dynamics 365 patterns.
Every automated match and posting should retain a link back to source bank, PSP, acquirer, invoice, merchant, or settlement data.
Provider, country, bank, currency, COBO/POBO and GL routing variations should be configured rather than hard-coded.
Settlement, commission, exchange, bank, AR/AP, GL and intercompany postings must balance before ERP export.
Unknown setup, ambiguous references, currency mismatches, duplicate candidates and unbalanced batches are held for review.
Card reconciliation is a two-sided process: first match the PSP/customer-facing payment to the invoice, then match the acquirer settlement back to that already matched payment.
Interbank reconciliation imports bank statements, classifies each line, applies ordered auto-matching rules, posts matched lines, and routes unresolved items to manual review.
Receive PSP/acquirer files or bank statements through provider, bank, TIS, FTP/SFTP, SWIFT, NACHA or manual upload.
Confirm active setup for provider, bank, merchant, terminal, card type, currency, entity and transaction category.
Apply priority rules: invoice/reference first, then amount/name, learning, balance, due/combinations or specialist country rules.
Create balanced ERP journals for AR/AP, bank, clearing, commission, exchange, GL, intercompany, COBO/POBO and ZBA flows.
Track matched, unmatched, posted, skipped, errored and unbalanced items with clear reason codes and reprocessing controls.
| Area | Executive takeaway |
|---|---|
| Matching sequence | Use deterministic, ordered rules. Do not let fallback rules override stronger invoice/reference matches. |
| Exact amount control | Normal invoice, card, refund and bank matches depend on exact amount/sign unless a documented tolerance, FX or country rule applies. |
| COBO/POBO/ZBA | Central collection/payment structures must identify the true billing or originating entity and post the appropriate intercompany or franchise/customer/supplier treatment. |
| Provider/bank variations | Worldpay, GlobalCollect, Stripe/POP, AMEX, Wells Fargo, Brazil Boleto, Colombia NIT, Mexico FX and France/Germany DD differences must remain explicitly configurable. |
| Capability | Needed design response |
|---|---|
| Configuration-first engine | Parsing, matching priority, GL routing, currencies, providers, banks and country exceptions need business-owned setup, not custom code branches. |
| Audit data model | Store source-file IDs, source lines, match rule IDs, transaction keys, posting keys and manual override history. |
| Exception workspace | Finance users need search, manual match, write-off, GL post, bucket movement and controlled skip capabilities. |
| Safe reprocessing | Re-runs must be idempotent: no duplicate journals, duplicate exchange differences, duplicate matched detail rows or repeated COBO transfers. |
The documents define clear gates: setup validation, exact matching, source traceability, balanced postings and manual review for exceptions.
The future model must absorb many country, provider, bank format and account-routing variations without creating brittle customisations.
Prioritise a canonical reconciliation model, then map card, bank, DD, COBO/POBO/ZBA and country rules into reusable configuration layers.
The reconciliation landscape is mature but complex. The safest Dynamics 365 path is not to replicate every legacy procedure line-for-line, but to preserve the business behaviours: ordered matching, entity correctness, separate economic components, balanced accounting, clear exception handling and full auditability from source file to ERP journal.
Prepared from the supplied Card Reconciliation business/technical documents and Interbank Reconciliation business/technical documents.