The payment moves money from one account to another. The remittance data tells the receiving AR team how to apply it — which invoices are being paid, in what amounts, with what deductions. For high-volume B2B payments, the reconciliation problem is often more expensive than the transaction cost. A $50,000 payment applied to the wrong invoices creates AR exceptions that take 2–4 hours to resolve. A $50,000 payment with full invoice-level detail and PO references reconciles automatically in seconds.
That difference in reconciliation cost is worth real money. And it's a product that most payment programs give away by design — because the infrastructure they built doesn't carry the data.
The ACH data problem
Standard ACH carries 80 characters of addenda data. That's enough for a reference number and a memo. For B2B payments where a single transaction covers 15–40 invoices with different purchase orders, discounts, and deductions, 80 characters is enough to create a reconciliation exception, not prevent one.
Same-day ACH has the same limitation. The rail is faster but not more data-rich. Programs built entirely on ACH infrastructure have a structural ceiling on remittance quality — because the rail can't carry what the receiver needs.
RTP and ISO 20022 are different. The 9,000-character data field carries full invoice-level detail: invoice number, PO reference, line item amounts, discount terms, deduction codes, remittance advice in structured format. A well-designed RTP payment can eliminate the reconciliation step entirely. The AR system reads the remittance data and auto-applies with no manual touchpoints.
Two-sided monetization
Remittance data has a two-sided monetization model. The payer side: charge for enhanced remittance formatting — the service of structuring outbound payment data so it meets the receiver's format requirements. The receiver side: charge for the remittance data delivery, the auto-match configuration, and the exception workflow management.
Most programs charge neither. The payer pays a transaction fee and assumes remittance is included. The receiver processes the payment manually and assumes the effort is part of AR. The program has delivered value to both sides and captured none of it.
The pricing model that works: a remittance data product with tiered pricing by volume and complexity. Base tier: standard remittance included. Enhanced tier: invoice-level matching, deduction codes, buyer-specific format templates. Premium tier: custom receiver format delivery, auto-match rate reporting, exception workflow integration.
The rail decision and the data ceiling
Remittance product design starts with the rail decision. A program running entirely on ACH has a hard ceiling on remittance data quality. A program with RTP in the rail mix has a data-carrying capacity that enables remittance products the ACH program can't offer.
This is why the rail selection decision is a revenue decision. Programs that selected ACH as the default rail to minimize transaction cost also selected the lowest remittance data capacity available — and foreclosed the remittance product revenue that comes with richer rails.
The redesign path is clear but not trivial: add RTP to the rail mix, design the remittance data model against receiver requirements, build the product packaging, and price against reconciliation cost avoided. Programs that do this typically find the remittance product is worth 3–5x the underlying transaction revenue on the affected payment volume.