How do payments physically get from our AP system to the bank?

NACHA format for US ACH; ISO 20022 XML (pain.001 for credit transfers) increasingly for wires and international payments; BAI2 for bank statement data coming back; and various bank-proprietary CSV layouts. ISO 20022 is the direction of travel globally - AP teams don't need to master the schema, but should know their bank's migration timeline and confirm their systems can produce and consume it.

Three routes: consolidate banking so fewer portals exist; build direct file/host-to-host connections from the ERP to each bank (high IT effort, ongoing spec maintenance); or run payments through a platform that connects to the banks once and gives AP a single execution workflow. The third has become the default for mid-market teams because it removes both the keying labor and the portal-credential sprawl.

A structured file of payment instructions (payee, account, amount, date) generated by your ERP or platform and transmitted to the bank for execution - NACHA for ACH, ISO 20022 or proprietary formats for other rails.

A global standard for richer, structured payment messages replacing legacy formats across wires and increasingly other rails; AP should care because it carries better remittance data and because banks are actively migrating - ask your bank for dates.

Direct transmission keeps you closest to your bank and avoids provider dependency, but you own file specs, connectivity, failures, and per-bank maintenance; a provider abstracts all of that and adds services (status, enablement, multi-rail) at the cost of an intermediary relationship.

The bank issues connection specs, credentials/keys, and a test environment; your IT configures the transfer, you map the ERP's payment file to the bank's spec, run parallel testing against the portal, then cut over. Budget weeks, not days, and re-test at every bank spec update.

Check the bank's acknowledgment/return files for item-level errors first, then look for limit breaches (daily exposure caps), funding holds, and OFAC review queues; escalate to your treasury contact with the file ID and affected trace numbers.

Portal upload is manual file submission through the bank website; host-to-host is automated server-to-server file exchange; API banking is real-time programmatic initiation and status retrieval - ascending order of automation and setup effort.

Every major ERP can output payment files from its payment run (electronic payment formats, payment journals, or bank-file add-ons); setup requires bank account configuration, format mapping to your bank's spec, and testing - the ongoing burden is keeping formats current per bank.

Treasury, not AP generally; individual named credentials only (no shared logins), inventoried centrally, with same-day revocation in the offboarding checklist and periodic recertification of who holds what.

Encrypting files in transit and at rest (PGP over SFTP is typical) and digitally signing them so the bank can verify origin and integrity - both should be mandatory for any file carrying bank account data.

Short term: pay through the bank portal manually with dual review to keep vendors whole. Then get the new spec, update the mapping, test against the bank's validation environment, and ask the bank for advance-notice commitments on future changes.

Supported formats and rails, file/API options and costs, cutoff schedules, acknowledgment and error reporting, spec-change notice periods, dual-control options, and what their implementation timeline actually looks like.

Stampli supports payment execution by letting AP release approved payments from one workflow while bank connectivity, provider routing, payment status, and ERP sync remain connected to the payment record. Instead of keying approved payments into separate bank portals, finance teams can keep invoice approval, payment approval, execution status, and reconciliation context in the same P2P system. Execution details still depend on payment method, provider, bank account, and ERP integration.