The thesis: cash application stops being a guessing game once the invoice travels with the payment.
Automated cash application has been a stubborn problem for years, not because AR teams lack effort but because most receipts arrive with too little structured data to match them to an invoice automatically. A bank deposit line with a customer name and an amount forces an analyst to guess, call, or wait for a remittance email that may never come.
That gap is closing from the payment side, not the ERP side. The Clearing House raised the RTP network transaction limit to ten million dollars in February 2025, and Federal Reserve Financial Services says FedNow reached the same ten million dollar limit as part of its 2026 enhancements, alongside a pilot aimed at accelerating request-for-payment adoption. Nacha already supports request-for-payment messaging in the ACH network through the pain.013 standard carried in CTX addenda, and Nacha's own material puts the baseline plainly: under twenty percent of B2B payments post to open invoices without manual intervention today.
Put those together and the opportunity is concrete. When a payment carries a structured invoice reference and settles instantly and irrevocably, AR can match it, release credit, and close the loop the same day, for far more of the receivables book than the current automation rate covers.
What changed in the payments environment.
Three things moved in the same direction in 2026. First, both major US instant-payment rails raised their per-transaction ceiling to ten million dollars, removing the limit that kept larger B2B settlements on wires and checks. The Clearing House reported that RTP payment value more than tripled in the first full month at the new limit, and its May 2026 update shows the network processing over 2.2 million transactions worth 8.6 billion dollars on a single record day, covering roughly 98 percent of bank-to-bank instant payments in the country.
Second, FedNow's own reporting shows the service reaching 1,800 financial institutions, including seven of the ten largest US banks and coverage of over half of all checking and savings accounts, with a pilot underway to push request-for-payment adoption further. Nick Stanescu, the Federal Reserve's chief FedNow executive, has described request for payment as functionality that has existed since launch, with growing momentum expected around instant bill-pay and e-invoicing use cases.
Third, the ACH network already carries a working version of this today. Nacha's request for payment message, built on the ISO 20022 pain.013 standard and delivered through CTX addenda, lets a seller transmit invoice-level payment details that a buyer's bank can return alongside the ACH credit. None of these three developments depends on the others, but together they mean structured, rail-carried invoice data is now available across ACH, RTP, and FedNow rather than one experimental channel.
Why this belongs in AR design, not a payments footnote.
None of this pays off automatically. A bank can deliver a structured remittance message and an ERP can still flatten it into one description field before matching even runs. The Randolph-Brooks case study from The Clearing House is a useful proof point in the other direction: the credit union processed over 273,000 RTP transactions worth more than 120 million dollars in six months without adding staff, because immediate, irrevocable settlement removed the day-two corrections and manual follow-up that used to consume that time.
AR should treat request-for-payment and structured remittance the same way treasury treats a payment-command object: one canonical record that carries the request, the settlement event, the match decision, and the credit-release action, so every rail maps into the same finance-owned contract instead of a bank-specific format.
The receivable-event record AR teams can build around.
A receivable event should connect the original request-for-payment message, the rail's settlement confirmation, the automatic match outcome, and the credit-release action. That lineage is what makes same-day credit release safe and what gives an auditor a single object to inspect instead of five disconnected screens.
Example receivable-event record
{
"receivable_event_id": "arevt_2026_07_rfp_0087",
"customer_id": "cust_31820",
"request_for_payment": {
"request_id": "rfp_2026_07_10491",
"invoice_refs": ["inv_10491", "inv_10508"],
"amount_minor": 1842500,
"due_date": "2026-07-24",
"channel": "RTP"
},
"payment_message": {
"rail": "RTP",
"settlement_status": "SETTLED",
"settled_at": "2026-07-24T15:02:11Z",
"irrevocable": true,
"remittance": [
{ "invoice_id": "inv_10491", "amount_minor": 922500 },
{ "invoice_id": "inv_10508", "amount_minor": 920000 }
]
},
"match_result": {
"status": "AUTO_MATCHED",
"confidence": 0.98,
"unmatched_minor": 0
},
"credit_release": {
"trigger": "SETTLEMENT_CONFIRMED",
"released_at": "2026-07-24T15:02:41Z",
"hold_before_minor": 1842500
},
"evidence_ref": "s3://ar-evidence/2026-07/arevt_2026_07_rfp_0087/"
}The structure stays useful across rails. RTP, FedNow, and ACH CTX will carry different message types and settlement timing, but AR still needs one lineage: the exact request sent, the exact remittance received, the exact match decision made, and the exact credit action taken.
Control design for request-for-payment cash application.
| Area | Design pattern | Evidence |
|---|---|---|
| Request-for-payment issuance | Send the invoice as a structured request rather than a PDF and a memo line, so the payer receives amount, invoice references, and a due date in one machine-readable message. | Request ID, invoice references, amount, due date, delivery channel, and payer acknowledgement. |
| Structured remittance capture | Treat the ACH CTX remittance addenda or the RTP payment message as the primary matching input, not a fallback when the bank memo looks readable. | Remittance array, invoice IDs, discount and deduction codes, payer reference, and match confidence score. |
| Same-day credit release | Because RTP and FedNow settlement is immediate and irrevocable, gate customer credit-limit release on confirmed settlement rather than a batch job that runs after the close of business. | Settlement event, value date, credit-hold state, release approver where required, and timestamp. |
| Unapplied cash workflow | Route anything that fails automatic matching into a queue with the structured data it did carry, so an analyst starts from partial facts instead of a bare deposit line. | Unapplied case ID, partial match candidates, reason code, owner, and resolution deadline. |
| Deduction and dispute handling | Capture short-pay and deduction reasons at the point of remittance so collections can dispute or approve them before the next statement cycle, not weeks later. | Deduction code, disputed amount, supporting document, decision, and closure date. |
| Collections prioritization | Feed aging, promise-to-pay history, and instant-payment enrollment status into one collections queue instead of working every past-due account the same way. | Account risk score, last contact, promise date, payment channel offered, and outcome. |
| Bank and rail reconciliation | Reconcile RTP, FedNow, ACH CTX, and card receipts against the same customer and invoice ledger, so AR does not run a separate spreadsheet per rail. | Rail identifier, bank reference, ledger posting, reconciliation status, and exception owner. |
| Audit evidence | Preserve the request message, the remittance data received, the match decision, and the credit-release event as one chain per invoice. | Request record, payment message, match log, override reason, approver, and retention period. |
The most important design choice is gating credit release on the settlement event itself. Instant, irrevocable settlement only creates cash-flow value if the ERP acts on it the same minute; a nightly batch job cancels most of the benefit and leaves the organization carrying the operational cost of instant rails without the working-capital upside.
Implementation checklist for AR operators.
List every inbound receivables channel: RTP, FedNow, ACH CTX, wire, card, and lockbox, and note which ones currently carry structured remittance data versus a flat deposit line.
Ask each bank whether it can deliver ACH CTX addenda and RTP or FedNow payment messages to the ERP as structured fields rather than a single free-text description.
Pilot request-for-payment issuance with a small set of repeat customers who already pay by ACH or instant transfer, and measure the match rate against the current baseline.
Build the unapplied-cash queue around partial structured data first, since even a failed automatic match usually carries an invoice reference worth showing the analyst.
Define the credit-release rule explicitly: what settlement event triggers release, which customers need manual review regardless, and who can override the rule.
Capture deduction and short-pay reasons as structured codes at the point of remittance, not as a note added later during a dispute call.
Track straight-through match rate by rail and by customer segment monthly, and use the worst-performing segment as the next quarter integration target.
Confirm retention and evidence requirements with audit before scaling: request message, remittance data, match decision, and credit-release event should all be retrievable from the invoice.
Sequence this by customer concentration. A handful of high-volume, cooperative customers moved onto request-for-payment and instant settlement will improve the match rate more than a broad rollout that never gets past a pilot list.
Audit evidence should follow the invoice, not the deposit.
Good AR evidence lets an auditor start at a cash posting and walk back to the exact remittance data received, the request-for-payment message that was sent, the match decision and its confidence score, and the credit-release event and its trigger. When settlement is instant and irrevocable, that chain matters even more, because there is no settlement delay left to catch an error before it reaches the customer's account.
Retention should sit close enough to the invoice record that finance can reconstruct the transaction without pulling a bank portal screenshot or a separate spreadsheet.
Constructive failure modes to design around.
Treating a request-for-payment pilot as a marketing project instead of an AR data project, so the structured fields never reach the matching engine.
Keeping the ERP bank feed as one flat description field, which throws away RTP and ACH CTX remittance data before reconciliation ever sees it.
Releasing credit holds on a nightly batch after instant, irrevocable settlement already happened hours earlier, which cancels most of the cash-flow benefit.
Building unapplied-cash review around the deposit amount alone, ignoring the partial invoice references that structured remittance already supplied.
Letting every bank connector define its own remittance field names, so the same invoice reference means something different depending on the rail.
Waiting for a single "instant payments are ready" moment instead of rolling out request-for-payment with the highest-volume, most cooperative customers first.
Each of these is a design prompt rather than a reason to wait. The rails already carry the data; the work is preserving it end to end and building the credit and collections rules that make instant settlement pay off operationally.
What AR teams should ask ERP and AR-automation vendors now.
Can the platform issue request-for-payment messages for open invoices and track payer acknowledgement before the due date?
Can it ingest ACH CTX remittance addenda and RTP or FedNow payment messages as structured fields, not a single memo string?
Can credit-hold release be configured against a settlement event rather than a batch schedule?
Can an analyst see why a receipt matched, which structured fields drove the match, and what remains unmatched?
Can deduction and short-pay reasons be captured as codes at the point of remittance and routed to the right owner automatically?
Can the match rate, unapplied balance, and average resolution time be reported by rail and by customer segment?
A credible vendor answer should describe structured request-for-payment issuance, rail-agnostic remittance ingestion, a settlement-triggered credit rule, and reporting that breaks match rate down by rail and by customer segment, not a general claim about AI-assisted matching.
Practical takeaway.
Cash application automation has usually been limited by the data a payment carries, not by the sophistication of the matching engine. RTP and FedNow at a ten million dollar limit, a FedNow request-for-payment pilot, and an ACH request-for-payment standard that already works together change that constraint. AR teams that build the request, settlement, match, and credit-release lineage now will convert more of their receivables book to same-day, evidence-backed processing as adoption of these rails keeps growing.
Sources.
- Federal Reserve Financial Services: 2026 Fees and Payment System Enhancements
- Federal Reserve Financial Services: FedNow Service, Two Years of Growth and Innovation
- PYMNTS: FedNow Readies Cross-Border Capabilities and Request for Payment Pilot
- The Clearing House: RTP Network Marks May Day with Record-Breaking Volume and Value
- The Clearing House: RTP Network $10 Million Transaction Limit Spurs High-Value Payment Surge
- The Clearing House: More than Instant Payments, How Randolph-Brooks Realized Operational Efficiencies with the RTP Network
- Nacha: ISO 20022 Request for Payment Now Live in U.S. ACH, Simplifies B2B Remittance
Targeted searches for public X and Twitter commentary on the FedNow request-for-payment pilot and the RTP network's ten million dollar limit returned only one directly relevant public post, from a payments-industry outlet summarizing the FedNow pilot announcement. That falls short of a credible set of two to four high-signal posts from regulators, network operators, or practitioners, so this article uses the primary sources above instead of an embed.