EDI Payments for B2B Transactions: How They Work, EDI 820 vs. 810, and When to Use Them

An EDI payment is a business-to-business payment whose remittance and instructions travel as a structured, standardized electronic message, most often the ANSI ASC X12 820. The EDI part is the data. It's not the money moving. That distinction trips up a lot of finance teams, and it's where this whole topic gets muddy.

Here's why it matters right now. B2B check volume has been falling for two decades, from 81% of payments in 2004 to 26% by 2025, according to Nacha's 2025 analysis of long-term payment trends. As checks retreat, finance teams are left choosing among electronic rails for each supplier relationship, and EDI is one of the older, more rigid, and more misunderstood options on the menu. The real question isn't "what is EDI" in the abstract. It's which rail fits which supplier, and how does that payment data flow back into your ERP without someone rekeying it.

Key Takeaways

• EDI is a data-interchange standard — the structured message format — not a funds-movement rail. An EDI 820 can instruct or accompany a payment, but ACH or wire actually moves the money.

• The EDI 820 is the payment order and remittance advice; the EDI 810 is the electronic invoice. Both follow the ANSI ASC X12 standard, and both are built to be read by machines, not people.

• EDI shines for high-volume relationships with a handful of large trading partners who already run EDI. It's heavy to stand up for the long tail of smaller suppliers.

• The failure mode is almost never the transmission. It's mapping drift — when one side changes a field or a spec flavor and the data stops landing cleanly in the other side's system.

• A multi-rail approach usually beats forcing every supplier onto one method. EDI for the big structured partners, ACH and virtual card for everyone else, with clean remittance flowing back into the ERP either way.

What is an EDI payment, and how is it different from ACH or EFT?

An EDI payment uses electronic data interchange, a set of standards for formatting business documents so computers can exchange them without human retyping, to carry payment instructions and remittance detail between trading partners. ACH and EFT, by contrast, are the rails that actually move funds between bank accounts. EDI describes the message; ACH and EFT describe the money.

That's the single most important thing to get straight, because AI explainers and vendor blogs blur these three terms constantly. You'll see "EDI vs ACH" framed as two competing payment methods, as if you pick one or the other. In practice they often work together. An EDI 820 can travel alongside an ACH transaction, telling the receiver exactly which invoices the incoming funds are paying. The 820 is the paperwork; the ACH entry is the cash.

A few clarifications that clear up most of the confusion:

• EDI is a data standard. It defines the structure of documents like invoices, purchase orders, and payment remittances so they can pass system-to-system.

• ACH is a batch funds-transfer network in the U.S., governed by Nacha rules, that debits one account and credits another.

• EFT is the umbrella term for any electronic funds transfer, which includes ACH, wire, and card transactions.

• An EDI 820 is a message that can order a payment, confirm one already made, or carry remittance data for cash application. It isn't itself a movement of funds.

So when someone asks whether EDI is faster or cheaper than ACH, the honest answer is that they're not the same category of thing. The better question is how the EDI message and the funds rail work together, and whether that combination fits the supplier you're paying.

What does "edi payment" actually mean in B2B?

In B2B, "EDI payment" is shorthand for paying a vendor using EDI-formatted transactions to handle the instructions and remittance, usually in a standing, high-volume trading relationship. The phrase gets used loosely to mean "we pay this supplier through our EDI setup," which typically bundles the payment order, the remittance advice, and sometimes the invoice itself into structured messages.

The reason the term feels slippery is that people use it to describe the whole arrangement, not one discrete action. When a large retailer says it "pays suppliers by EDI," it means purchase orders, invoices, and payment remittances all move as X12 documents across an established connection, with the actual funds settling over ACH or wire underneath. EDI is the connective tissue between two accounting systems. The money still rides a bank rail.

How does EDI compare to ACH, EFT, and API payments?

EDI, ACH, EFT, API, and virtual card sit at different layers of a payment, so comparing them side by side is really about matching a method to a supplier's size, systems, and volume. The table below lays out what each one is and where it fits.

EDI and API sit at the message and instruction layer; ACH, wire, and card move the funds. A given payment often combines one from each layer.

The practical takeaway is that these aren't five options you rank first to last. You match them to the supplier. A 4,000-store trading partner that lives in EDI gets EDI. A regional service vendor you pay twice a month is far better served by an ACH payment, which is cheaper to set up and doesn't require either side to maintain a mapping spec. ACH's reach is a big part of why it's the default for the long tail: the network moved 35.2 billion payments worth $93 trillion in 2025, according to Nacha's 2026 ACH Network volume statistics.

How do EDI payments work, step by step?

EDI payments work by having two trading partners agree on document standards, map their internal data to those standards, transmit the structured messages over a secure channel, and translate the incoming messages back into each system. The funds settle over a bank rail in parallel. It's less a single transaction than a choreographed handoff between two accounting systems.

Walk through the sequence and it becomes concrete:

1. Trading partner agreement. Both sides agree on which EDI documents they'll exchange (820, 810, 850 purchase orders, and so on), which standard and version, and how they'll connect.

2. Data mapping. Each party maps its own ERP or accounting fields to the corresponding positions in the EDI document. This is the labor-intensive part, and it's where most of the ongoing maintenance lives.

3. Transmission. The sender's system generates the EDI file and sends it over a value-added network (VAN), a direct AS2 connection, or SFTP.

4. Translation and posting. The receiver's EDI translator parses the incoming document and posts the data into its system, dropping an invoice into AP and a remittance into AR cash application without manual entry.

5. Funds settlement. Separately, the actual payment moves over ACH or wire, referencing the 820 so the receiver can match cash to invoices.

The payoff, when it works, is that nobody rekeys anything. The invoice your supplier generated flows straight into your AP system, and your payment remittance flows straight into their AR. That's the same no-rekeying promise that drives invoice processing automation more broadly — eliminate the manual touch, and you eliminate the errors and delay that come with it.

What happens between sender, VAN, and the receiver's ERP?

Between the sender and the receiver, the EDI message usually passes through a value-added network or a direct connection, gets translated at each end, and lands in the receiver's ERP as posted data rather than a document a person has to read. The connection mechanics are where the "how do EDI transactions actually move" question gets answered.

A VAN acts like a private post office for EDI. The sender drops a document into its VAN mailbox; the network routes it to the receiver's mailbox; the receiver picks it up on its own schedule. VANs add reliability, audit trails, and translation services, which is why large trading networks have relied on them for decades. The alternative is a direct AS2 connection, which sends documents peer-to-peer over the internet with encryption and signed receipts, cutting out the intermediary. Some partners simply exchange files over SFTP.

Whichever channel carries the message, the real value shows up at the ERP boundary. When the 820 remittance lands and posts automatically, your AR team isn't opening a PDF and typing invoice numbers into a cash-application screen. The data arrives pre-structured. That elimination of rekeying is the entire economic argument for EDI, and it's why the setup cost can pencil out for partners you exchange thousands of documents with each month.

Where do EDI payments break down?

EDI payments break down at the mapping layer far more often than at the transmission layer. The file almost always gets there. What fails is the data landing cleanly in the receiver's system after one side changes something the other side didn't expect.

A few common failure modes:

• Mapping drift. One party adds a field, renames a segment, or changes how it populates a reference number. The transmission succeeds, but the receiver's translator misreads or drops the data, and suddenly payments don't match to invoices.

• Spec flavors. X12 is a standard, but trading partners implement it with their own conventions and required segments. A document that's valid for one partner can fail another partner's validation rules.

• Version mismatches. Partners running different X12 versions have to reconcile the differences, which adds maintenance every time either side upgrades.

This is the honest tradeoff with EDI: its rigidity is both the feature and the flaw. The strict standard is what lets two systems exchange data without a human in the loop. That same strictness means a small change on one side can quietly break the flow on the other. Finance teams feel this as the "syncing issues" that lead to confusion and duplicated effort — the payment went out, but it didn't post correctly, and now someone's reconciling by hand anyway. The teams that run EDI well treat the mapping as a living relationship that needs monitoring, not a one-time integration you set and forget.

Protect cash flow with modern AP

Modernize AP to cut costs, speed approvals, and mitigate payment risk — gaining the real-time visibility to protect cash flow and scale with confidence.

Download the whitepaper

What are the EDI 820 and EDI 810 transaction sets?

The EDI 820 is the payment order and remittance advice, and the EDI 810 is the electronic invoice. Both are ANSI ASC X12 transaction sets, standardized document types with defined segments and elements, and each maps to a specific step in the buy-pay cycle. The 810 comes from the supplier asking to be paid; the 820 goes from the buyer explaining a payment.

These two numbers do most of the work in EDI-based AP. An 810 replaces the paper or PDF invoice, carrying line items, quantities, prices, totals, and the business payment terms like net 30 or 2/10 net 30 in a structure your AP system can validate against a purchase order automatically. The 820 replaces the check stub and the emailed remittance, telling the supplier which invoices a payment covers, what was deducted, and what references to apply. Deeper mechanics of the 820 as an electronic remittance advice, including how it carries adjustment reason codes and ties to cash application, are worth understanding in detail, and we cover the remittance advice and how to automate it side of the 820 separately. Here the focus is on how these transaction sets fit the payment flow.

What is in an EDI 820, and how does cash application use it?

An EDI 820 carries the detail a receiver needs to apply cash correctly. Its whole reason for existing is to make cash application automatic on the receiving end. A typical 820 includes:

• The payment amount and the paying and receiving parties

• The list of invoices the payment covers

• Any deductions or adjustments, with reason codes

• The reference numbers that tie the payment to open items

Think about what the receiver's AR team does with it. A payment arrives for, say, $84,000. Without structured remittance, someone has to figure out which of the supplier's open invoices that covers, whether a short-pay reflects a dispute or a discount, and how to code the adjustment. The 820 answers all of that in the data: it itemizes the invoices, states the amounts applied to each, and carries reason codes for any deductions. The AR system reads it and clears the open items automatically. That's the difference between a payment that reconciles itself and one that generates a research ticket.

For AR teams on the receiving side, this is exactly why structured electronic remittance matters — it's the mechanism that lets you support accounts receivable with electronic payments instead of drowning in manual matching. The richness of the 820 is its real advantage over a bare ACH entry, which often arrives with little more than a trace number.

How does the EDI 810 invoice fit the AP workflow?

The EDI 810 fits the AP workflow as the structured invoice that feeds three-way matching without anyone keying data from a PDF. It arrives from the supplier, posts into your AP system, and gets validated against the matching purchase order and receipt automatically.

The 810 earns its keep on the buyer side by removing the entry step. In a manual process, an invoice comes in, someone enters the header and line data, and only then can the system compare it to the PO and the goods receipt. The 810 arrives already structured, so the match runs the moment the document lands. A price that doesn't match the PO or a quantity that's off surfaces immediately instead of days later. The 810 is one of several invoice-capture methods that plug into a modern accounts payable process, alongside PDF capture and supplier portals, and for high-volume trading partners it's often the cleanest of them.

When should a B2B finance team actually use EDI?

A B2B finance team should use EDI when it exchanges a high volume of documents with a limited number of large trading partners who already run EDI, and when the value of automated, line-level data flow justifies the setup and maintenance cost. For the long tail of smaller suppliers, EDI is usually the wrong tool.

The economics are what decide it. Standing up an EDI connection means mapping, testing, and ongoing maintenance for each trading-partner relationship. That cost amortizes beautifully across thousands of monthly documents with a major partner. It makes no sense at all for a vendor you pay twice a quarter. And the cost of manual AP is real on the other side of the ledger: the median cost to process a single invoice runs about $10.18 for top-quartile performers versus roughly $21.40 at the overall median, according to APQC's 2024 Open Standards Benchmarking data. EDI attacks that cost, but only where the volume is there to attack.

The market backdrop reinforces the case for moving off paper without mandating any single rail. Global B2B payment transaction value is forecast to reach $224 trillion by 2030, up from $186 trillion in 2025, according to Juniper Research's 2025 B2B Payments report. The B2B payments market itself is projected to grow from $11.69 trillion in 2024 to $15.88 trillion by 2030, a 5.2% compound annual growth rate, per Research and Markets' 2025 B2B Payments Global Report. Scale that large rewards automation, but it doesn't tell you which method fits which relationship. That's a per-supplier decision, not a company-wide mandate.

Which suppliers are a good fit for EDI, and which are not?

Suppliers that are a good fit for EDI are large, high-volume trading partners with mature EDI capabilities and a standing relationship; suppliers that are a poor fit are smaller vendors, one-off payees, and anyone without existing EDI infrastructure. The dividing line is volume and existing capability, not size for its own sake.

Good-fit signals:

• You exchange hundreds or thousands of documents a month with the partner.

• The partner already runs EDI and can meet your spec without a heavy build on their end.

• The relationship is long-term and stable enough to justify maintaining the mapping.

Poor-fit signals:

• The vendor is small, paid infrequently, or lacks EDI capability entirely.

• Forcing EDI would mean the vendor has to build infrastructure they'll use for one customer.

• The spend is better matched to a card or a simple ACH transfer.

There's a real-world tension here that finance teams know well. Push a payment method onto a supplier that doesn't fit their operation, and they push back — the same way smaller vendors balk when they're told to accept cards and eat the interchange, or when approval routing for one method collides with another. Running several rails at once is normal and healthy; the mistake is forcing a single method across a supplier base that isn't uniform. This is the same fit question that runs through how electronic payment solutions meet different supplier needs, and EDI is just one answer among several.

How does EDI data flow back into your ERP?

EDI data flows back into your ERP through a translator that maps incoming transaction sets to your system's fields, so remittance and invoice data post automatically without rekeying. The clean flow into the ERP is the entire point — and it's also where EDI's rigidity makes the mapping quality do all the heavy lifting.

When it's set up right, an 810 posts as an invoice ready for matching, and an 820 posts as remittance ready for cash application. Nobody retypes anything, and the general ledger reflects the activity without a batch of manual journal entries. When the mapping drifts, you get the opposite — data that lands in the wrong field or fails to post, and an AP or AR clerk cleaning it up by hand, which defeats the purpose. Modern AP platforms address this by maintaining the mapping and connection layer across systems like NetSuite, Sage Intacct, Microsoft Dynamics 365 Business Central, and Acumatica, so the structured data reaches the ledger cleanly regardless of which rail carried the payment. That managed-integration layer is what turns "we send EDI" into "our EDI actually reconciles," and it's closely tied to how supplier payments automation removes the enrollment and reconciliation burden across a mixed supplier base.

Run EDI and every other rail through one managed AP platform

The hard part of a multi-rail payment strategy isn't sending any single payment. It's that every rail has its own enrollment, its own remittance format, and its own way of flowing back into your ERP — and your AP team ends up maintaining all of it. Corpay closes that gap. We run virtual card, ACH, and check alongside EDI-style structured remittance, enroll your suppliers onto the method that fits them, and return clean remittance data into 180+ ERP integrations so cash application isn't a manual chore.

That means you don't have to force every supplier onto one method or build and babysit the mapping for each connection yourself. Your high-volume trading partners keep their structured, line-level data flow. Your long-tail vendors get ACH or a virtual card without you standing up an EDI spec they'd never justify. And the remittance lands in your ledger the same clean way regardless of which rail moved the money. If you're weighing how EDI and the other electronic rails fit together across a real supplier base, our payments automation platform is built to run them side by side, and the broader AP automation suite handles the invoice-capture and approval steps upstream. See how the rails and your ERP connect through our integrations before you decide which supplier belongs on which method.

Frequently Asked Questions

What is an EDI payment?

An EDI payment is a B2B payment where the payment instructions and remittance detail move as a standardized electronic data interchange message, typically an ANSI ASC X12 820, between two trading partners. The EDI message carries the data; a bank rail like ACH or wire moves the actual funds.

What does EDI payment mean?

It means paying a supplier using EDI-formatted transactions to handle the payment order and remittance, usually within an established, high-volume trading relationship. In practice the phrase describes the whole structured-messaging arrangement, not a single discrete payment action.

Is EDI the same as ACH or EFT?

No. EDI is a data-interchange standard for formatting business documents, while ACH and EFT are the rails that move money between accounts. An EDI 820 can accompany or instruct an ACH payment, but the EDI message itself is instructions and remittance, not a transfer of funds.

What is an EDI 820?

The EDI 820 is the Payment Order/Remittance Advice transaction set in the ANSI ASC X12 standard. It can order a payment, confirm one already made, or carry the remittance detail — invoices paid, deductions, and references — that lets a receiver apply cash automatically.

What is the difference between EDI 820 and EDI 810?

The EDI 810 is the electronic invoice a supplier sends to request payment; the EDI 820 is the payment order and remittance advice a buyer sends to explain a payment. The 810 feeds the AP matching process, and the 820 feeds AR cash application.

Who provides EDI payment services?

EDI payment capability typically comes from value-added network (VAN) providers, EDI software and translator vendors, and AP automation platforms that build EDI-style structured remittance into a broader multi-rail payment service. Larger organizations sometimes run direct AS2 connections with major trading partners instead of using a VAN.

Is EDI still worth it for mid-market AP teams?

For mid-market teams, EDI is worth it selectively — for the handful of large trading partners you exchange high document volume with, where automated line-level data flow justifies the setup and maintenance. For the rest of the supplier base, ACH, virtual card, and structured remittance through a managed platform usually deliver the same no-rekeying benefit with far less overhead.

David Luther

Product Marketing Program Manager

David Luther, MBA is a product marketing program manager with years of experience in commercial banking, finance, and technology sectors, with research and writing appearing in financial publications.

Payments Automation

AP Automation