Resolve an unmatched transaction

An unmatched transaction does not necessarily indicate a defect. It can be outside the supported settlement scope, lack a compatible open document, fall below the current confidence threshold, or have incomplete data.

Invunion v1 reconciles incoming customer payments to issued invoices and outgoing credit-note refunds to issued credit notes. It does not promise supplier payables or automatic N:N batch matching. UI and matching behavior can change.

Prerequisites

• Access to the transaction, its bank description, date, amount, currency, and direction.
• Access to issued invoices and issued credit notes.
• Permission to reconcile manually or ignore a transaction.
• Source evidence that can establish the correct document relationship.

Steps

1. Classify the transaction. Determine whether it is an incoming customer payment, outgoing refund, internal transfer, payroll, tax, bank fee, supplier payment, loan, or another movement. Only the first two categories belong to the supported v1 matching scope.

2. Check the settlement view. The transaction list defaults to settlement scope and can indicate that other movements are outside it. If the item appears only after showing all transactions, that may be expected. Do not force out-of-scope cash movements into an issued-invoice reconciliation.

3. Verify direction and document kind. An incoming transaction needs an issued invoice. An outgoing refund needs an issued credit note. A normal issued invoice is not compatible with an outgoing transaction.

4. Verify currency. Transaction and document must use the same currency for current matching. Do not manually apply an exchange rate to create an artificial match; no ECB FX conversion behavior is claimed.

5. Check the open balance. Confirm that the invoice is unpaid or partially open and not cancelled. A paid invoice or a document with no available open amount is not a normal candidate.

6. Compare amount and date. The automatic matcher prefilters by a compatible amount range and date proximity. A valid but unusual payment can therefore lack a candidate. Use source evidence to decide whether manual reconciliation is appropriate.

7. Check references. Search the invoice list by invoice number and external reference. Compare those values with the bank’s structured reference and description. Watch for truncation, prefixes, punctuation, and payer-entered text.

8. Check customer association. Confirm that the bank counterparty or resolved payment method belongs to the invoice customer. If the payment came through an aggregator, the displayed bank counterparty may represent the platform rather than the end customer.

9. Check whether the transaction is ignored. Ignored transactions cannot be matched. A transaction can be excluded by the system, a reconciliation rule, or a user. Only reverse that state when you have determined that it truly belongs in settlement scope.

10. Create a manual reconciliation when verified. Open the reconcile action, search for the issued invoice or credit note, select it, and review the default allocated amount. Reduce the amount for a partial settlement as necessary, then submit.

11. Choose an honest unresolved state. If no supported document exists, leave the transaction unmatched. If it is deliberately outside reconciliation scope, use the available ignore action according to your team’s policy.

Expected result

The transaction is either linked to a verified compatible issued document with the correct allocated amount, or it remains intentionally unmatched or ignored with a defensible reason. The goal is accurate classification, not a zero-unmatched dashboard.

Edge cases and troubleshooting

• Correct invoice exists but is missing from manual candidates: verify its status, open amount, type, currency, counterparty context, and the transaction direction.
• Payment is partial: allocate only the actual payment amount. The invoice should retain an open balance.
• Payment covers several invoices: use controlled manual allocations if the current interface presents compatible records. Automatic many-to-many discovery is not promised.
• Several payments settle one invoice: reconcile only available remaining amounts and verify each allocation.
• Outgoing refund is absent: confirm the document is an issued credit note for the same counterparty and has a refundable open amount.
• Internal transfer is ignored: this is expected when Invunion recognizes movement between the tenant’s own known accounts.
• Score is below 50: the matcher ignores the candidate. A manual match is acceptable only with independent evidence.
• Imported invoice data is wrong: correct the underlying invoice record or source process. Do not compensate by matching to the wrong record.

Security and sandbox notes

Bank descriptions can include personal names, account identifiers, and references. Limit access and redact unrelated details when asking for help. A manual match changes financial state; apply separation-of-duties controls appropriate to your organization.

In sandbox, all Mock ASPSP transactions are synthetic. Use synthetic invoices too. A successful manual sandbox match validates the workflow, not production availability or compatibility with a specific real bank.

Next step

Use Review match confidence to assess future suggestions. If the expected transaction or invoice data is missing rather than merely unmatched, gather details with Contact support with diagnostics.

Updated 6 August 2026

Was this article helpful?

Feedback helps us improve the next version of this guide.

Yes Not yet Tell us what is missing