Why Richer Payment Data May Not Reach Your Bank Report

A payment can reach your bank while the information needed to match it to an invoice fails to reach your reconciliation system. The credit is visible, but its reference is shortened or missing. Your team has cash to allocate—and an exception to investigate.

It is tempting to ask the payer for better information or loosen the matching rules. Before doing either, establish whether the information was absent from the payment or simply absent from the report.

That distinction is central to ISO 20022 payment reporting. A richer payment instruction gives a bank more information to work with. It does not, by itself, guarantee that the file your finance team imports will expose that information.

The report is a representation, not necessarily a reproduction

Think of three separate points: the payment data the bank receives, the report the bank delivers, and the fields your reconciliation system imports. Information visible at one point is not proof of what appears at the next.

J.P. Morgan’s FAQ explicitly acknowledges that an ISO 20022 settlement can contain more information than a corporate customer’s existing banking interface can report. For legacy MT statements and advices, the bank says it maps enhanced ISO payment data where there is sufficient space, while avoiding disruption to existing reference and data mappings.

This is one bank’s documented approach, not a universal rule. But it makes the reporting problem concrete: richer information may have to fit into an output designed around existing fields and established customer processes.

Preserving those mappings has a practical purpose. A change that exposes more data but displaces a reference your system already uses could undermine an otherwise reliable import. The trade-off is that continuity of reporting does not necessarily mean completeness of reporting.

A small omission can block a sound match

Consider a hypothetical customer with two open invoices, each for €12,500. Their references are INV-10481 and INV-10482. A €12,500 payment arrives with the full reference INV-10481, but assume the bank-delivered report shortens that field to INV-1048.

On the amount and reported reference alone, both invoices fit. The payment contains the distinction needed to select the right invoice; the report does not.

No cash is missing in this example. What is missing is the information that makes automatic allocation defensible. Relaxing the rules to accept either match would turn a visible exception into a risk of misallocation, rather than repair the information gap.

The same reasoning applies when a reference is blank. A blank field in an imported report is evidence about that report and import—not conclusive evidence about what the payer sent.

What a trailing “+” actually establishes

Some reporting behaviour provides a useful clue. J.P. Morgan says it adds a trailing “+” where possible when field content has been truncated.

In that documented use, the marker establishes that content was omitted from the field. It does not reveal the omitted text, establish that the missing text was an invoice reference, or tell your team how to reconstruct it.

The qualification matters just as much as the marker. Because the bank says “where possible,” an unmarked field does not establish that it is complete. Nor does it establish that the original payment contained no further information.

This is a one-way diagnostic signal: the documented marker supports a truncation finding; its absence does not rule truncation out. Do not build a completeness check around an unmarked field without confirming the behaviour of your particular bank report.

Network preservation does not settle the reporting question

It may seem that preserving richer data within the payment network should solve this problem. It addresses a different part of it.

Swift describes Transaction Manager as maintaining full transaction data centrally and protecting in-scope data elements through validation and integrity rules. Its documented scope excludes messages converted through contingency processing for MT senders and their subsequent ISO 20022 legs.

Even where those protections apply, they do not establish what a bank exposes through a corporate statement, interface or reporting feed. Data preservation within the network and data delivery to the finance team are separate outcomes.

For payment reconciliation, the decisive question is therefore not just whether information has been preserved, but whether it is available in the specific output your team uses.

Find the gap before changing the process

Start with a credit your team cannot confidently allocate. Compare the bank-delivered file with the fields shown in your reconciliation system. If the full reference is in the file but not in the application, investigate the import or display mapping before requesting a different bank feed.

If the bank-delivered file is already incomplete, ask the bank for field-level answers:

• Was the full reference present in the payment received? Ask about the specific credit, not simply whether the bank supports ISO 20022.
• How is that information represented in this report? Establish the destination field, space constraints and relevant mapping or truncation behaviour.
• Can an available reporting option carry what your matching process needs? Verify this with a representative output. A portal showing more information does not prove that an automated feed carries it too.

The answer determines the remedy. An import problem calls for a mapping fix. A bank-report limitation calls for discussion of available reporting changes. If the necessary reference was absent from the payment itself, the payer’s remittance information becomes the issue to address. If the original contents remain unconfirmed, keep that uncertainty explicit rather than assigning a cause.

Before changing matching rules or switching feeds, test that the proposed change exposes the missing information while preserving fields your existing process relies on. A richer format label is not a substitute for a usable sample.

Finally, keep cash receipt and invoice allocation separate. A visible credit with an incomplete reference is an allocation problem. If no credit can be found, that is a different investigation; neither a truncation marker nor network data preservation establishes that the funds arrived.

Conclusion

Richer payment data helps reconciliation only when the necessary information reaches the system doing the matching. Before treating a missing reference as a payer error—or a missing payment—establish what the bank received, what its report exposed and what your application imported. That evidence points to the right fix without weakening otherwise sound reconciliation controls.

For requesting more information about how we can help reach out to us. We're here to help and answer any questions you may have.

Contact us!