Key concepts

The rail doesn't know your customer, and no single "customer" record does either. An ACH payment names the payer by routing and account number only; it says nothing about the legal entity or the invoice. Upstream, "customer" splits into the legal entity that owes, sold-to, ship-to, bill-to and payer; credit limits sit at the parent while orders arrive per ship-to. A hospital group's shared-service center might pay for its twelve hospitals from one bank account, so the bank shows you one payer while your credit team manages twelve customers.

Business checks on sellers, payers and customers

An AR fintech runs full KYB (know your business) on its sellers: legal entity, owners of 25% or more, a control person, sanctions. Payers get lighter checks: bank-account validation, fraud signals, sanctions. A seller granting terms has no legal KYB duty, but it does carry strict-liability sanctions exposure, and it may pull a consumer report on a guarantor, not on an officer who isn't personally liable.

Name-to-account checks are voluntary in the US. The Fed announced a Payee Name Verification service in December 2025, launch unconfirmed, and under UCC 4A-207 a bank may rely on the account number when name and number disagree.

You build and keep the mapping from bank account to payer to credit account to invoice yourself, and cash application and credit control both depend on it.

Six lifecycles run on the same sale, and they disagree by design.

• The account: applied, approved, active, on hold, cash in advance, closed.
• The order: entered, credit-held, released, shipped, delivered, invoiced.
• The invoice: issued, accepted, approved, scheduled (payer side), paid (in the payer's eyes), applied (in the seller's), closed.
• The payment: initiated, received, settled, funds final.
• Cash application: unidentified, unapplied (payer known, invoices not), partially applied, applied, on account.
• Collections: current, past due by aging bucket, dunning, promise to pay, placed, written off, recovered.

"Settled" and "final" mean different things on every rail:

Bankruptcy can undo even a final payment: payments received in the 90 days before a customer files (a year for insiders) can be clawed back as preferences, unless a defense such as ordinary course of business applies. Because a paid invoice can reopen, every reversal has to reverse the application, re-age the invoice and restart dunning, or your customer ends up chasing the wrong people.

Most facts here are owned by someone other than you.

The classic breaks: card deposits arrive net and batched against gross invoices; a lockbox deposits one total for fifty checks; an ACH return lands after the cash was applied; a payer deducts its wire fee. Book fees, returns and corrections as their own entries, never edits. When the ERP and the bank disagree, the bank wins on cash, the ERP on what's owed.

The ledger also carries the loss reserve. CECL (ASC 326, the expected-credit-loss rule) applies to trade receivables: lifetime expected loss from day one, pooled by risk, never zero on current balances, with price concessions and credit memos stripped from loss history. ASU 2025-05 (July 2025) lets any company assume current conditions persist for current receivables, and private companies may also count collections after the balance-sheet date, for years beginning after December 15, 2025.

Nobody is the system of record for remittance or for deduction reasons, so whoever captures them best ends up owning the matching and a clean loss history.

Rules come in layers, and every party on the sale sets some of them.

Terms are a price. "2/10 net 30" means giving up 2% to be paid 20 days early, about 37% a year; a longer term is a discount nobody books. Say a packaging supplier offers 2/10 net 30 on a $10,000 invoice: a customer that pays on day 10 sends $9,800, so the supplier paid $200 to get its cash 20 days sooner. The seller sets its terms only until a large payer, an insurer or a lender sets them instead, which is partly why sales and credit pull against each other.

The other big rule is who starts the payment. In a pull (ACH debit, PAD, card) the seller does, and carries authorization and return risk; in a push (ACH credit, wire, RTP, FedNow, check) the payer carries fraud and misdirection risk. On card fees, the seller decides, the network caps, and state or provincial law can forbid.

A sale's cost and rights depend on the day each thing happened. Prices change between PO and shipment, promotions carry date ranges that deductions cite months later, limits change mid-order, and Visa US interchange changes each April and October.

Store the price, promotion, terms, fee schedule and card product that applied to each order, invoice and payment at the time, rather than a pointer to today's version, because deduction fights turn on which version applied. If a snack maker ran a 10% promotion in March and a retailer deducts it from a June payment, checking the deduction means pulling the promotion terms as they stood in March.

The standards mostly exist, but the data often still doesn't arrive.

• Order to invoice: ASC X12 sets 850 (purchase order), 855 (acknowledgment), 856 (ship notice), 810 (invoice), 812 (credit or debit adjustment) and 824 (application advice, often a rejection), alongside payer portals, emailed PDFs and e-invoicing networks. A US e-invoice exchange framework went market-ready in 2023; I found no US or Canadian B2B e-invoicing mandate (October 2026).
• ACH: CCD+ carries one 80-character addenda field; CTX up to 9,999 addenda records, enough for an X12 820 (the EDI remittance advice).
• Wires and instant payments: ISO 20022 on Fedwire (since July 2025), RTP, FedNow and Canada's Lynx (since November 2025). Providers report RTP's free-text remittance field at 140 characters.
• Everything else: check stubs and X9 image files; Level 2 and 3 card data; BAI2, camt.053 and lockbox files from banks; a different API for every ERP. Canada's AFT is to gain ISO 20022, no date.

Remittance gets lost in four places: at the payer, whose AP team emails it to a generic inbox; at origination, where the payer's bank portal offers a short free-text field; at the receiving bank, which doesn't report addenda unless asked; and at aggregation, when one payment covers fifty invoices and the file comes days later.

The rails can carry the data, so the product fix belongs at those same edges: payer portals, inbox parsing, full addenda reporting from the bank, and clean order and delivery data so the invoice is accepted first time.

An order-to-cash flow touches a dozen organizations, and the ones that matter most never sign your contract: the payer's AP team, your sponsor bank, and whoever insures or finances the receivables.

So this behaves like a network business as much as SaaS: every new seller brings payers who have to change behavior, and every payer already has someone else asking it to pay a different way.

ERP vendors are partners and competitors: several mid-market ERPs now embed payments through partners, by their own account. I'd watch for the one that takes the "pay" button.

Keep the layers apart: each has its own enforcer and its own penalty.

FinCEN exempts a payment processor from money transmitter status only if it facilitates a purchase or bill payment, through clearing systems open only to regulated institutions, under an agreement with at least the seller (ruling FIN-2014-R009). State rules are converging: 31 states had passed the CSBS model money transmission law by April 2026, with more since. And since April 27, 2022, FINTRAC has treated invoice payment services as MSBs, exempting only an entity that receives payments for a payee without passing them on, so in Canada an AR platform that collects and then remits to the seller is usually in scope.

Phone payments catch people out. When an AR clerk keys card numbers from a VoIP call, those systems fall into PCI scope (the card industry's security standard). A pay link where the payer enters the card keeps the seller out.

Most of an AR team's week is exception work, and every exception runs on its own clock.

Card processors set their own chargeback response deadlines, often shorter than Visa's.

Nacha counts R29 toward the 0.5% unauthorized threshold; crossing 3% administrative or 15% overall triggers an inquiry. The clocks are short for business accounts, which is why sellers like pulling from businesses, and why a missed day usually means a lost case.

As a rule of thumb, on payments loss follows whoever started the payment: the payer usually eats a bad push, the seller a bad pull. On credit, the seller eats the loss unless it moved it beforehand, to an insurer, a factor, a guarantor or a secured position.

Say a customer gets an email that looks like it's from your AR team, with "new bank details", and wires $48,000 there. If its bank followed the agreed security procedure, the customer bears the loss, and your invoice is still open, so your seller is left with a customer who believes it already paid. Nacha's 2026 fraud rules leave UCC 4A unchanged; the buyer's controls are in procure to pay.