EDI 820 Remittance Advice Builder

What an 820 Remittance Advice Is

The X12 820 is the payer's structured explanation of a payment: which invoices are being paid, how much is being paid against each, any discount taken, any adjustment applied, and where the money is going. In the typical workflow the actual money moves through a bank channel (ACH, wire, or check), and the 820 travels alongside — through a VAN, AS2, SFTP, or email — telling the payee's AR system how to apply the funds across their open invoice ledger. For suppliers doing electronic cash-application, the 820 is what turns a mystery "$2,642.48 from Mega Mart" line on the bank statement into a clean auto-matched receivable roll-up. The 820 closes the procurement loop that starts with an 850 and runs through 855/856/810.

BPR Header and ENT / RMR Detail

An 820 opens with a BPR (Beginning Segment for Payment Order/Remittance Advice) that carries the transaction handling code (I for remittance-only, C or D when the 820 itself moves money), the total amount, the payment method (ACH, CHK, FWT…), and the payment effective date. A TRN segment carries the trace number that ties the 820 back to the bank transaction. N1 loops identify the payer (N1*PR) and payee (N1*PE). Then comes the detail area: ENT/RMR loops, one per invoice being remitted, with RMR carrying the invoice number (qualifier IV), the action code (PO payment in full, PI partial, AJ adjustment), the amount paid, the invoice total, and any discount taken. Optional DTM*003 (invoice date) and REF*VV (voucher / reference) segments attach to each invoice.

How This Tool Generates a Valid 820

Paste or drop an 810 invoice and the tool appends an invoice entry to the remittance with the invoice number, date, and total auto-filled — amount paid defaults to the invoice total, action defaults to PO (payment in full). Drop another 810 to add more. The first import also seeds the payer (from the invoice's bill-to) and payee (from remit-to), and auto-registers a reply partner by swapping the inbound envelope so the outbound 820 ships back to the invoicing vendor. Per-invoice you can change the amount paid, set PI for partial payments, add a discount, reference a voucher, or mark an adjustment (AJ). The total on the BPR header auto-recalculates from the invoices, and validation flags common mistakes — a PO whose amount doesn't reconcile with the invoice total and discount, or a PI whose amount equals or exceeds the invoice total. Envelope: ISA/GS(RA)/ST(820). Body: BPR · TRN · optional CUR · N1 loops for payer and payee · per-invoice ENT + RMR (+ optional DTM*003 and REF*VV) · SE. Generated files parse cleanly through the EDI File Parser. Pairs with the 810 Invoice Builder, the NACHA/ACH File Explorer, and the Positive Pay Generator.

What This Tool Isn't

First-cut scope targets the most common workflow: BPR01 = I (remittance-only, payment moves separately via ACH or wire). C / D handling — where the 820 itself conveys bank routing and account detail to initiate payment (BPR05 through BPR15) — is not emitted yet. Healthcare-specific 820 variants (premium payment for insurance enrollment) with their extended ENT and payer-contact segments are also out of scope. The tool doesn't perform AP ledger lookup, doesn't initiate the actual ACH / wire transfer, doesn't reconcile against statements returned from the bank, and doesn't handle transmission. For healthcare 820s, ledger-driven pay runs, or payment initiation, Ask James.

EDI Integration with Your Systems

Most of the EDI integration work I do bridges X12 and whatever formats your systems produce and consume — modern APIs, database tables, spreadsheet exports, flat files, or legacy platform-native formats. Inbound direction: a partner's 850/856/997 lands in the exact shape your order entry, WMS, or AP system expects. Outbound direction: validator-clean 810/850/855/856/820 built from your systems' native data — handling partner-specific variations, acknowledgments, and exception workflows.

Need the Full Pay-Run Workflow?

In production, the 820 is the last mile of an AP pipeline that runs: open-invoice aging report → payment-run selection with approvals → NACHA ACH batch generation → positive-pay file to the bank for check-fraud protection → 820 emission per vendor with per-invoice detail → cash-app reconciliation when the payee reports the deposit back. I build that loop end-to-end — QuickBooks, IBM i, or an in-house ERP feeding a pay engine, bank integration for ACH and wire, 820 with per-partner formatting against each vendor's implementation guide, and an audit trail that survives SOX review. For AP automation, Ask James.