Interfaces & standards

The standards are mostly there. The data 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); plus 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 unstructured 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 arrives days later.

Remittance is lost at the edges, not on the rail, so the product fix is at the edges too: payer portals, inbox parsing, full addenda reporting from the bank, and clean order and delivery data so the invoice is accepted first time.

Sources: X12, Fed Payments Improvement, Nacha CCD and CTX guide.

Ask an expert: what share of invoices go by EDI, portal and email, what's the rejection rate per channel, and what share of payments arrive with usable remittance on each rail?

AP speaks four families of standards, and the buyer picks which ones its suppliers must use.

• Orders and invoices: X12 850 (purchase order), 856 (ship notice) and 810 (invoice); UBL invoices on Peppol; the DBNAlliance exchange framework; emailed PDFs; supplier portals; and, for US federal suppliers, the Treasury's free Invoice Processing Platform.
• Payment instructions to the bank: Nacha files (CCD, CCD+, CTX); ISO 20022 pain.001, with pain.002 status reports back; check-print files plus Positive Pay issue files; card APIs and Visa straight-through messages; the CPA-005 file for Canadian AFT.
• Remittance: X12 820, CTX addenda, email or portal advices, and the ISO 20022 remittance model the Business Payments Coalition published in 2024.
• Bank reporting: BAI2, camt.053 and camt.054.

EDI is the incumbent e-invoice between large North American trading partners (X12). Beyond it, Ardent says the average organization can receive electronic invoices from 57% of its suppliers, but "electronic" there includes a PDF by email that someone scans.

Where the buyer drops the remittance

1. AP splits the payment from the explanation. Money goes through the bank; remittance goes by email, often to the supplier's generic inbox.
2. The bank portal truncates it to a short free-text field, even when the rail carries thousands of characters.
3. The ERP doesn't fill the fields. CTX can carry a full 820, but only if AP's system builds one.
4. One payment, many invoices. Batching makes remittance long, and long remittance is the first thing dropped.

On the buyer's side remittance is a choice: the rails can carry it, and AP decides whether to fill the fields. The seller's cash-application problem starts here.

Ask an expert: in 2026, what share of invoices at a large buyer arrive as EDI, PDF, portal entries and true network e-invoices, and who owns the remittance file?

A spend platform speaks four families of standards.

• Authorization: ISO 8583 messages through the issuer processor, turned into webhooks the platform answers in 2 to 3 seconds; just-in-time funding moves the company's money at the same moment.
• Merchant data: category codes (ISO 18245, though each network keeps its own list), 25-character names, and Level 2 and 3 data (tax, then line items), which only the merchant can send. In the US, Level II no longer earns a lower rate except on fuel, and Level 3 counts only once Visa validates it.
• Bank card files for outside software: Visa Commercial Format (VCF 4.x) or Mastercard's CDF3, sent by SFTP after the company authorizes its bank. One Canadian bank charges $1,000 to set it up plus $0.35 a transaction.
• Out to finance: ERP journals through accounting APIs; payroll files; Nacha PPD files for reimbursements. Since March 20, 2026, Nacha requires wage credits to say "PAYROLL"; reimbursements aren't wages, so banks advise a different description.

Accounting APIs now cost money: two accounting vendors started charging for API access in 2025 and 2026 (trade-press reports).

Where the receipt gets lost

1. The rail doesn't carry it. An authorization has an amount, a merchant and a code, not items or purpose.
2. The bank file comes late. A bank card reaches expense software as a daily file after clearing. A platform that sees each authorization can ask for the receipt while the employee is still at the counter (my inference).
3. The names don't match. The receipt shows a trading name; the card shows a 25-character descriptor, sometimes behind a payment facilitator's prefix.
4. Line items are optional, and patchy in travel. I found no e-receipt standard with real North American adoption.

Sources: Visa Merchant Data Standards Manual, Visa US interchange, Nacha; webhook timings from two issuer processors' documentation, file fees from a Canadian bank's FAQ.

Card rails move money and a merchant's identity, not a purchase's purpose; the product is the bridge from authorization data to a receipt and a GL code.

Ask an expert: for customers who keep their bank card and use our software, how late and how lossy are the VCF and CDF3 feeds compared with our own authorization stream?

The standards are old, the dialects many, and the signal you want is often missing.

• Numbers. E.164, and in the NANP the NPA-NXX-XXXX format (area code, exchange, line). Mobile and fixed share the same area codes, so line type needs a lookup.
• Messaging. Platforms reach aggregators over SMPP (the SMS industry's binding protocol) or HTTP. Billing counts segments (the parts a long SMS is split into), and error codes are provider-specific.
• Porting. An LSR (local service request) goes to the losing carrier, an FOC (firm order commitment, the agreed date) comes back, and the NPAC record flips. A simple port may be validated on four fields only: number, account number, ZIP code and passcode.
• Caller identity. STIR/SHAKEN (ATIS-1000074) signs each call. Attestation "A" means the signer knows the customer and verified its right to the number; "B", it knows the customer but not the number; "C", it's passing traffic it didn't originate. Since September 18, 2025 a provider must sign with its own SPC token (the credential iconectiv issues to eligible providers). Since March 25, 2026 a terminating provider that blocks on analytics must say so with SIP code 603+.
• 911. NG911 carries calls over SIP with location in the signaling as PIDF-LO (a standard location object).
• RCS. GSMA's Universal Profile (4.0 finalized March 2026). Google's API returns 404 when a user can't be reached; fallback is your job.
• WhatsApp. Cloud API only since the On-Premises API ended October 23, 2025. Business-scoped user IDs in webhooks must be supported since April 2026. Embedded Signup v2 is deprecated on October 15, 2026.

Sources: STI-GA, TransNexus, Kelley Drye, Google, Meta.

An A attestation proves who signed the call and what they know about the caller, not that the call is wanted or legal.

Ask an expert: which upstream interface breaks most often (TCR, Somos, porting, Meta, Google), and how much warning do you usually get?