How to Send EDI 820 Remittance Advice for Freight Invoices

What an EDI 820 Does in a Freight Payment Cycle

An EDI 820 is not the payment. It's the message that tells a carrier what a payment covers, or confirms that one already went out. That distinction trips up more AP teams than you'd expect, especially when someone in finance assumes the 820 is the money moving.

The SEEBURGER breakdown of the X12 820 describes it plainly: an ANSI X12 EDI 820 Payment Order is an EDI payment or remittance advice message that tells a supplier how much will be paid for delivered goods or services, or that the transfer has already happened. In a freight context, the standard defines three legitimate uses for the transaction set: to order a financial institution to make payment to payee(s) on behalf of the sending party, to report the completion of a payment to payee(s) by a financial institution, and to give advice to the payee by the payor on the application of a payment made with the payment order or by some other means. Look at FCA US's carrier remittance implementation guide for a concrete example of how a shipper actually uses this. FCA US uses the 820 Remittance Advice to inform carriers that a check has been processed and is in the mail, and the transaction is built to echo key fields from the freight bill, whether that's an EDI 210 Freight Invoice or a paper freight bill. That's the whole point of the 820 in freight payment: it closes the loop the 210 opened.

If you're dealing with European carriers or shippers running EDIFACT instead of X12, the equivalent transaction is REMADV. As EDI2XML's comparison notes, the message code in EDIFACT standard for the Remittance advice message is REMADV, and it functions as the analog of EDI 820, used mainly in Europe. Same job, different envelope.

What You Need Before You Start

Before you build a single segment, confirm the following with your trading partner and your bank:

• Version agreement: 004010 or 005010, and whether the carrier's translator will reject anything outside that version
• Delimiter and envelope conventions your trading partner agreement specifies, including whether GS01 must read "RA"
• Whether the carrier wants a direct EDI 820 over AS2 or VAN, or expects the remittance wrapped as ACH addenda instead
• Confirmation from your ACH originating bank that it supports CTX with multiple addenda records, not just a single PPD+ or CCD+ addenda
• Vendor/carrier master data in your ERP AP module that matches the carrier's own reference numbers on the original 210 or paper freight bill
• A translator (Cleo, IBM Sterling, SPS Commerce, TrueCommerce) already configured to output 820/CTX, not just inbound 210 parsing

On the ACH question specifically: the transaction set often doesn't travel to the carrier as a standalone EDI file at all. It gets folded into the bank transfer itself. That's the CTX decision, and it shapes every segment you build next.

Building and Sending the 820: Step by Step

Here's the segment-by-segment build for a carrier freight remittance, whether it ends up going out over AS2 or riding inside an ACH batch.

1. Decide the delivery mode first. If your bank supports it, CTX (Corporate Trade Exchange) is the ACH Standard Entry Class code built for this. CTX is a Standard Entry Class code that can contain multiple addenda records which provide additional information on each transaction, also called remittance information such as invoice numbering. Compare that to PPD+ or CCD+, where you are limited to at most one addenda record per transaction and a maximum length of 80 characters — fine for a single invoice, useless for a carrier you're paying against forty open freight bills in one batch.
2. Build the envelope. ISA/GS/ST headers open the interchange, with the functional group identifier set to Functional Group=RA for Payment Order/Remittance Advice.
3. Populate BPR (Beginning Segment for Payment Order/Remittance Advice) with payment method, total amount, and banking details. This is the segment that carries the ODFI and RDFI routing information: BPR06 and BPR07 relate to the originating depository financial institution, BPR08 identifies the type of bank account, and BPR09 is the account of the company originating the payment.
4. Add TRN to give the payment a traceable identifier. The TRN segment is used to uniquely identify a payment order/remittance advice — this is the number the carrier's AP team will ask about when they call.
5. Add N1 loops for payer and payee. The N1 loop allows for name/address information for the payer and payee, and separate iterations let you distinguish the paying legal entity from the entity actually being paid when a carrier group has multiple operating subsidiaries.
6. Populate one RMR loop per invoice, referencing the carrier's original 210 or 810 invoice number and paid amount. If there's a deduction or short-pay, add an ADX segment — but know its scope is narrow: the ADX loop can only contain adjustment information for the immediately preceding RMR segment and affects the RMR04 amount calculation. If the adjustment doesn't net to that specific invoice, it has to move to a separate, outer ADX loop instead.
7. Close with SE/GE/IEA and transmit. Direct EDI goes out over your existing AS2 connection or VAN. CTX-wrapped remittance gets handed to your bank's ACH origination process instead, where the 820 content becomes addenda records on the underlying credit entry.

Testing Before Go-Live

Don't send a carrier your first 820 cold. Run it through your translator's compliance check first, then walk a full cycle: a 210 comes in, your AP system schedules payment, the 820 goes out, and the carrier's own system reconciles it against the open invoice. If you're using AS2, confirm the carrier's system returns a 997 acknowledging the interchange structurally validated — that's separate from whether the payment amounts and references actually make sense to their AR team, so don't treat a clean 997 as proof the remittance detail was usable.

If you're routing through CTX, get your bank or the carrier's bank to confirm they can parse the addenda count you're sending before you go live with real dollars attached. Mismatched addenda expectations are the single most common go-live blocker on this transaction, and they're invisible until someone opens the file.

How You Know the 820 Worked

Three signals tell you the implementation is solid, not just technically compliant:

• The carrier's AP/AR team matches your RMR references against their open 210 or 810 invoices and closes the item without a manual lookup or a phone call to your shared services desk
• Your own ERP shows the payment applied against the correct invoice number, not sitting in an unapplied-cash suspense account waiting for someone to investigate
• No 997 rejection on the interchange, and no returned or bounced ACH entry from the bank on the funds side

If the carrier keeps calling to ask "what is this payment for" even after the 820 posted cleanly on your end, the segments are syntactically fine but the reference numbers you're echoing don't match what their system expects. Go back to the trading partner agreement and confirm which qualifier they want in RMR01.

The Failure Mode Everyone Hits: CTX Addenda Truncation

CTX has generous capacity on paper. CTX has a limit on the number of addenda records — 9,999 per entry — but it is so high as to be almost unapproachable in practice. That's the theoretical ceiling. The practical failure shows up well below it, because the receiving bank or the carrier's own parser often has a much lower documented limit than the NACHA maximum.

Here's the scenario: you batch forty freight invoices into a single CTX-wrapped 820 to reduce transaction fees. The ACH entry clears. The carrier gets their money. But their bank's addenda parser truncates at a line count below what you sent, and half the invoice-level detail never makes it into their AR system. The payment is real. The remittance detail is gone. Now the carrier is calling asking which invoices got paid, and you're pulling bank confirmations to prove you sent the detail in the first place.

The fix is boring but effective: split large multi-invoice remittances into smaller batches under whatever line limit the trading partner has actually documented, not the NACHA ceiling, and reconcile addenda counts against your outbound file before transmission. Confirming this after a carrier calls asking where their money went is too late.

Where the 820 Fits in Your Carrier-Connectivity Stack

For shippers running EDI across dozens or hundreds of carriers, the 820 is one leg of a longer cycle that includes tender (204), tender response (990), status updates (214), and freight invoice (210). Multi-carrier platforms increasingly expose these as configurable templates instead of requiring you to hand-build segments per lane.

None of this replaces the 820 itself. It just changes how much hand-mapping your team does per carrier onboarding. The 820/CTX combination remains the backbone of high-volume carrier payment reconciliation in North America, and it isn't going anywhere just because your TMS added an API layer on top.

If you haven't built one yet, start with a single low-volume carrier relationship, prove the RMR-to-invoice matching works cleanly on both sides, and only then decide whether CTX wrapping is worth the addenda-limit conversation with your bank. Get that one lane clean before you scale it to the rest of your carrier base.