BPR
Beginning segment for payment order/remittance advice: transaction handling code, total amount, payment method, and bank routing details.
A payer’s notice of payment: which invoices are being paid, for how much, and how. Buyer (payer) to supplier (payee), often with a copy to the bank. This page covers what the 820 is for, the segments you meet when you open one, the documents it travels with, where it tends to go wrong, and how it moves over AS2 into your systems on Files.com, which receives, parses, validates, and routes it as configuration.
No credit card required · 7-day free trial · Live in minutes
The 820 closes the order-to-cash loop. A buyer sends it to tell the supplier that payment is being made, and it carries the payment amount and method, the trace number that ties the notice to the funds moving through the bank, the payer and payee, and a remittance section that lists each invoice being settled with the amount applied and any adjustments.
In practice the 820 does two jobs that used to be one check and one stub. The payment order instructs the bank; the remittance advice tells the supplier how to apply the cash. When the two travel separately, the supplier’s cash-application team matches the deposit to the remittance by the trace number.
In document order, the segments that carry the 820's meaning. A partner's implementation guide says which are required and which fields each must hold.
Beginning segment for payment order/remittance advice: transaction handling code, total amount, payment method, and bank routing details.
Trace number that links the remittance to the payment moving through the banking system.
The payment or effective date.
Payer and payee, one loop each.
Remittance advice: an invoice number, the amount paid against it, and the original amount.
An adjustment to an invoice, with a reason code, when the amount paid differs from the amount billed.
Short pays without an adjustment reason are the classic 820 problem: the RMR shows less than the invoice and no ADX explains why, and cash application stalls while someone emails. The other is timing, when the remittance arrives days before or after the funds and the trace numbers have to be matched by hand.
The 820 rarely moves alone. These are the documents that precede, answer, or settle it.
The supplier’s bill for goods or services delivered against a purchase order.
See The 810A notice that an amount owed is being adjusted up or down, with the invoice it applies to and the reason.
See The 812The receipt that says an EDI transmission arrived and was parsed, with any syntax errors found.
See The 997A partner sends the 820 over AS2, SFTP, or FTPS, and it lands in that partner’s inbox folder on Files.com with the transport receipt recorded. From there it is a workflow, not a project: TransformScript parses the X12 natively into the JSON, CSV, or XML your ERP or WMS reads, content validation flags a document whose contents are wrong before anything ingests it, and an automation routes the result to the system and the people who act on it.
Outbound is the mirror image. Your system exports its record, TransformScript builds the 820 the partner’s guide specifies, and the file dropped in the partner’s outbox goes out over AS2 with automatic retries until the MDN confirms delivery. Every transmission in both directions is in the audit log, and delivery monitoring alerts when a 820 that was due never arrives. The full picture is on the EDI software page.
What teams ask about the 820 and how it moves on Files.com.
An EDI 820 is the X12 Payment Order/Remittance Advice. A payer sends it to say a payment is being made, how, and which invoices it settles, so the payee can apply the cash without a paper check stub.
No. The 820 is the notice and the instruction. The money moves through the banking system (ACH, wire, or check), and the trace number in the 820 is what ties the notice to the deposit.
Both are remittance documents. The 820 is the general commercial payment order; the 835 is the healthcare claim payment and remittance advice used by insurers to pay providers.
Yes. Files.com is a standards-compliant RFC 4130 AS2 endpoint, and a 820 sent by a trading partner lands in that partner’s inbox folder with a signed MDN receipt returned to the sender. Partners who exchange over SFTP or FTPS connect to the same platform and the document lands in the same place.
Yes. TransformScript parses the X12 820 natively and writes the JSON, CSV, or XML your systems ingest, as a step in the workflow that fires when the document arrives. Outbound, the same engine builds a 820 from your system’s export and drops it in the partner’s outbox for delivery.
Start the 7-day trial, turn AS2 on, and exchange certificates with your partner. The 820 lands in their folder, parses into the record your system reads, and every transmission carries a signed receipt.
No credit card required • Free for 7 days • Live in minutes