Instant Settlement Is Not Instant Reconciliation: The B2B Integration Test

The money has arrived, but the invoice remains open. For a supplier, that is the difference between receiving an instant payment and completing an automated business process. Faster settlement does not tell the accounting system which receivable to clear, whether a deduction was agreed or how to allocate one payment across several invoices.

The Federal Reserve Bank of Kansas City’s October 30, 2026 briefing examines that gap. It identifies unresolved message-field definitions and invoicing constraints rather than presenting instant payments as sufficient for straight-through processing—the completion of a workflow without manual intervention.

For B2B instant payment reconciliation, the procurement question should therefore be concrete: can this integration apply the received money to the correct invoices, under agreed accounting rules, without someone repairing the data? A successful payment demonstration alone cannot answer it.

Two routes for remittance data

Remittance information explains what a payment is paying for. It can travel with the payment or arrive separately, linked by a reference.

The FedNow Service Readiness Guide describes optional remittance information, including free text, designated fields and separately referenced information. That is documented flexibility, not a guarantee that every payment contains structured invoice data—or that the receiving business gets that data intact.

Structured remittance carried with a payment offers a potential advantage: allocation instructions and money can be processed through a linked message flow. The implementation still needs agreed meanings for identifiers and amounts, plus preservation through bank interfaces and accounting adapters. “Supports ISO 20022” is not an adequate acceptance criterion for ISO 20022 remittance data.

Separately exchanged invoice data can support a richer business document and an independent invoice lifecycle. But it creates a joining problem: the recipient must reliably associate that document with the payment. The Kansas City Fed’s September briefing identifies detached remittance data and missing automated bank feeds as obstacles to reconciliation.

Neither route is inherently superior. The following acceptance framework is editorial analysis, not a network requirement or a report of measured performance.

Five tests before calling it automated

1. Resolve the invoice identifier, not just the payment reference

Construct test cases using the business’s actual identifier conventions: leading zeros, punctuation, repeated invoice numbers across suppliers and invoices issued by different legal entities. Include a single payment covering several invoices and several payments against one invoice.

The proposed pass condition is an unambiguous match within the correct customer account and legal entity. A payment identifier should remain distinct from an invoice identifier, with a traceable relationship between them.

Matching by amount alone should not pass. Where identifiers conflict or are missing, the system should preserve the receipt as unapplied cash or route it to an exception process—not silently close the most plausible invoice.

2. Prove field preservation across every interface

Compare the originating remittance payload with what reaches the receiving bank interface, integration layer and accounting system. Check identifiers, currency, allocation amounts and adjustment information wherever the agreed format supports them.

Test permitted boundary lengths, character handling and missing fields. Require the adapter to expose rejected or unsupported content rather than quietly dropping it.

For separately exchanged data, add delayed delivery, unavailable documents and changed document versions. The proposed pass condition is a durable, authenticated association between payment and remittance, with enough retained evidence to reconstruct the allocation. An inaccessible reference is not successful data delivery.

3. Complete the accounting import

A notification in a bank portal is not an accounting posting. ERP payment integration should demonstrate the complete path from receipt information to cash entry, invoice allocation and the resulting outstanding balance.

Test partial payments, authorised discounts, credit notes and overpayments against explicitly configured policies. Replaying the same notification must not create a second receipt: this is idempotency, meaning repeated processing has the same business effect as processing once.

The pass condition is the expected accounting result with an audit trail—not simply a successful API response. Measure elapsed time to correct posting separately from payment arrival. Instant receipt followed by a scheduled overnight import may still be useful, but it is a different operating outcome.

4. Verify the counterparty’s actual capabilities

The October Kansas City Fed briefing distinguishes institutions that can send and receive instant payments from receive-only participants. Network participation therefore does not establish a complete two-way business workflow. Source

For each intended trading relationship, document sending capability, receiving capability, remittance formats, business-facing interfaces and request-for-payment support. Test the intended customer service, not just the bank’s underlying connection.

The FedNow guide distinguishes a request for payment, `pain.013`, from a customer credit transfer, `pacs.008`. The Kansas City Fed also cautions that request functionality may not yet support straight-through processing for complex invoicing. A request, its response and the eventual payment should therefore have separate workflow states. Neither a request response nor an outbound payment instruction should substitute for the bank-provided evidence required to recognise receipt. FedNow guide

5. Make exceptions recoverable

Deliberately submit an unknown invoice reference, duplicate notification, unsupported adjustment and unavailable accounting endpoint. Establish what happens when payment arrives before its separately delivered remittance.

A controlled exception should retain the money record, original data, failure reason and responsible operational queue. Recovery should allow safe replay without duplicate posting. Manual corrections should be attributable and auditable.

Security belongs in this test too. As design requirements, authenticate data sources, restrict access to invoice detail and avoid automatically fetching arbitrary remittance URLs. Separate authority to change reconciliation rules from authority to approve sensitive corrections.

Price the completed workflow

The relevant cost comparison is not simply the fee per instant payment. It is the cost of reaching a correct accounting outcome.

A proposed business-case model should include:

• Initial work: identifier mapping, bank and ERP adapters, counterparty onboarding, security controls and acceptance testing.
• Recurring operation: connectivity, processing charges, monitoring, document storage and connector maintenance.
• Residual exceptions: investigation, customer contact, correction and audit effort.

Evaluate these against the existing process using comparable payment and invoice populations. Report straight-through processing rates alongside incorrect allocations and exception-resolution time; a higher automation rate is not progress if it conceals accounting errors.

No cost savings or performance gains are established by this framework. Those require implementation evidence. A sensible deployment would start with counterparties that can meet the agreed data contract, then expand after both routine and exception cases pass.

Instant settlement can shorten the wait for money. Closing the invoice requires a second achievement: preserving the payment’s business meaning all the way into the books.

*Methodology and limitations: This analysis uses desk research from the supplied, attributed primary-source excerpts and summaries. Full documents were not independently retrieved, and no product testing, interviews or cost benchmarking were conducted. The acceptance tests and cost model are editorial proposals; they do not establish the capabilities of any particular bank, ERP or connector.*

Sources and References

• Federal Reserve Bank of Kansas City, B2B Payments: How Instant Payments May Facilitate Straight-Through Processing for Businesses, October 30, 2026.
• Federal Reserve Bank of Kansas City, B2B Payments: Business Processing and Challenges to Achieving Straight-Through Processing, September 25, 2026.
• Federal Reserve, The FedNow Service Readiness Guide.