An EDI 820 is one unbroken stream of X12 segments that declares its own delimiters, so Excel drops the whole payment into a single cell. Pick your file and every RMR remittance line comes back as a row: payer, payment date, invoice number, amount paid, discount, and adjustment reason. It parses in this browser tab, so a file carrying live routing and account numbers never leaves your computer.
Last updated August 2026
EDI 820 and 823 to CSV converter
Pick a file and get a spreadsheet. Nothing is uploaded: the conversion happens in this browser tab.
| Date | Payer | Invoice | Paid |
|---|
Preview shows the first 25 remittance lines. The download and the copy include every row and every column.
Have a PDF statement instead of a data file? The bank statement converter reads PDFs and writes XLSX, CSV, OFX, QFX, QBO and QIF.
X12 was designed so two computers could agree on a payment without a human in the middle, and it shows. Open an 820 in Excel and you do not get a bad table, you get no table at all. These are the six things that break.
Segments end with a tilde, not a line break, so a file holding 400 invoices can arrive as a single unbroken line. Excel puts all of it in cell A1 and Notepad shows you one endless row.
X12 does not fix the separators. Position 4 of the ISA envelope sets the element separator and the last character sets the segment terminator, so one partner sends asterisks and tildes and the next sends pipes and carets. A saved import scheme built for one file silently mangles the next.
Payment level segments and invoice level segments are stacked in the same stream with different shapes and different lengths. No single delimited import can turn that into one rectangle, because the file is not rectangular.
The payer name is on an N1 segment and the payment date is inside BPR, both of which appear before the invoice lines. Split the file naively and every invoice row comes out with no payer, no date, and no trace number attached.
REF, DTM and N1 all appear at several levels of the same transaction. A REF near the top is a payment reference; a REF inside an RMR loop describes that one invoice. Position decides meaning, so a flat find and replace gets it wrong.
Routing numbers, account numbers, trace numbers and invoice numbers are zero padded text. Excel strips the leading zeros and flips the long ones into scientific notation, which corrupts them for good.
The converter reads the envelope first, learns the delimiters the file actually uses, then walks the transaction in order so payment level facts land on every invoice row underneath them.
Each RMR remittance line becomes a row with the invoice number, the amount paid, the gross invoice amount, and the discount taken in their own columns, which is the shape cash application actually needs.
Payer and payee from the N1 loop, the total from BPR, the effective date, the payment method, and the ACH trace or check number from TRN are joined onto every invoice row in that payment.
The parser takes the element separator and segment terminator from the ISA envelope rather than assuming asterisk and tilde, so files from different trading partners all work without reconfiguring anything.
ADX adjustment amounts and reason codes are kept next to the invoice they belong to, so you can see why a customer paid $9,400 against a $10,000 invoice instead of guessing at it later.
Download a clean CSV or copy the whole table straight into a sheet, then load it into your ERP, your cash application tool, or a pivot table.
An 820 carries live bank routing and account numbers on both sides of the payment. This converter runs in your browser tab with no upload, so the file never touches a server.
Nothing to install, no account, and the file never leaves the browser.
X12 remittance files come from your bank's reporting portal, from a trading partner's EDI feed, or out of your ERP's outbound folder. Extensions vary: .edi, .x12, .820, .txt, or nothing at all.
Tip: Any extension works, the content is what matters.
Pick the file in the converter above. It reads the ISA envelope to learn the delimiters, then walks every ST transaction in the file, including multi payment files.
Tip: Several payments in one file is normal.
Download the CSV and sum the Amount Paid column for a payment. It should equal that payment's BPR total. Once it ties, the rows are ready to apply against open invoices.
Tip: A total that does not tie means an adjustment was missed.
These files show up wherever money arrives with paperwork attached. The person opening one is almost always trying to answer the same question: which invoices did this deposit actually pay, and why is the amount short.
Turn a customer's remittance advice into an invoice level worksheet, then apply the deposit without retyping 200 invoice numbers off a PDF.
Match a bank reported deposit to the 820 or the lockbox 823 that explains it, and prove the day's receipts tie out.
Check an outbound 820 before it goes to the bank, and confirm the payment total, routing details, and invoice detail are what the ERP intended to send.
Validate an 820 map during a go live, segment by segment, against the trading partner's implementation guide instead of reading raw X12 in a text editor.
Sample test cash receipts, evidence that remittance detail supports the recorded revenue, and trace individual deductions back to a reason code.
Reconcile the premium payment 820s a plan sponsor sends to a health insurer against the enrollment the carrier billed for.
An EDI 820 is the ANSI ASC X12 transaction set called Payment Order/Remittance Advice. It does one of two jobs, and sometimes both at once: it instructs a bank to move money to a payee, and it tells the payee which invoices that money covers. The 820 sits in the X12F finance group alongside the other banking sets, and in practice you meet it in three situations. A buyer sends one to its bank as a payment order. A buyer sends one straight to a supplier as a remittance advice for a payment already on the way. And a plan sponsor sends one to a health insurer to pay group premiums.
The distinction matters when you convert one, because the first element of the BPR segment says which job this particular file is doing. A handling code of D means make the payment and send no remittance, I means remittance information only with no money attached, and C means the payment and the remittance travel together.
An 820 is a stream of segments, each starting with a two or three character tag. Envelope segments wrap the whole thing, the BPR and TRN pair carries the payment, and a repeating RMR loop carries the invoice detail. This is what you will find in a typical file.
| Segment | Name | What it carries |
|---|---|---|
| ISA | Interchange Control Header | Sender and receiver IDs, date, control number, and the delimiters the rest of the file uses. |
| GS | Functional Group Header | Groups transactions of the same type, with its own control number. |
| ST | Transaction Set Header | ST01 holds 820, which is how you confirm what you are actually looking at. |
| BPR | Beginning Segment for Payment Order/Remittance Advice | The payment itself: total amount, credit or debit, method, both sides' routing and account numbers, effective date. |
| TRN | Trace | The number that ties the paperwork to the money: an ACH trace number or a check number. |
| CUR | Currency | Present when the payment is not in the default currency. |
| REF | Reference Identification | Extra references such as a customer, contract or batch number. Meaning depends on where it sits. |
| DTM | Date/Time Reference | Payment, invoice and period dates, tagged by a qualifier. |
| N1 loop | Name | Payer and payee names and IDs, with N3 and N4 carrying the address. |
| ENT | Entity | Splits remittance by entity when one payment covers several divisions or accounts. |
| RMR loop | Remittance Advice Accounts Receivable Open Item Reference | One per open item: invoice number, amount paid, gross amount, discount taken. |
| ADX | Adjustment | The amount and coded reason for anything deducted from what was billed. |
| SE, GE, IEA | Trailers | Segment counts and matching control numbers that close ST, GS and ISA. |
BPR is the payment. Everything else in the transaction describes it. It is the segment your treasury team cares about, because it holds the money and the bank instructions in one line. These are the elements you will use most.
| Element | Field | Typical values |
|---|---|---|
| BPR01 | Transaction Handling Code | C payment with remittance, D payment only, I remittance only, U split payment and remittance. |
| BPR02 | Monetary Amount | The total payment. Your converted invoice lines should sum to this. |
| BPR03 | Credit/Debit Flag | C credit, D debit. |
| BPR04 | Payment Method Code | ACH, CHK for check, FWT for wire, NON when no money moves. |
| BPR05 | Payment Format Code | CTX corporate trade exchange, CCP cash concentration plus addenda. |
| BPR06 to BPR09 | Originating bank details | Qualifier 01 for ABA routing, the payer's routing number, DA for demand deposit, the payer's account. |
| BPR12 to BPR15 | Receiving bank details | The same four fields for the payee side of the payment. |
| BPR16 | Effective Entry Date | CCYYMMDD, the date the money is meant to settle. |
One caution before you build anything against this table. Element numbering past BPR10 shifts a little between X12 versions and between trading partner guides, and some guides add a business purpose code at the end. Always check the implementation guide your partner or bank published for the version you are actually receiving, rather than assuming 4010 and 5010 are identical.
RMR is the invoice detail, and it is the reason anyone converts an 820 to a spreadsheet in the first place. One RMR segment appears per open item the payment touches, so a single check covering 180 invoices produces 180 RMR segments inside one transaction.
| Element | Field | Notes |
|---|---|---|
| RMR01 | Reference Identification Qualifier | IV or IK for an invoice, PO for a purchase order, AZ for a credit memo. |
| RMR02 | Reference Identification | The document number itself, which is what you match against open AR. |
| RMR03 | Payment Action Code | PI paid in full, PO payment on account, AJ adjustment. |
| RMR04 | Monetary Amount | What was actually paid against this item. |
| RMR05 | Total Invoice Amount | The gross amount billed, before discount or deduction. |
| RMR06 | Discount Amount | Terms discount taken, for example the 2 percent on 2/10 net 30. |
When RMR04 is less than RMR05 and no discount explains the gap, look for an ADX segment underneath. ADX01 is the adjustment amount and ADX02 is the coded reason, and that pair is the difference between a clean cash application and a deduction your AR team spends a week chasing.
Four X12 sets get mixed up constantly because all four involve invoices or money. They are not interchangeable, and knowing which one you have decides what you can do with it.
| Set | Name | Who sends it | What it tells you |
|---|---|---|---|
| 820 | Payment Order/Remittance Advice | A payer, or a payer's bank | A payment and the invoices it covers, across any industry. |
| 823 | Lockbox | The bank running your lockbox | What the lockbox received and deposited on your behalf, payment by payment. |
| 835 | Health Care Claim Payment/Advice | A health plan | Payment to a provider with claim level adjudication and denial detail. |
| 810 | Invoice | A seller | What is owed. No payment exists yet, so there is nothing to apply. |
The pairing people find most confusing is 820 and 835, and the short version is industry. The 820 is the general purpose remittance used in retail, manufacturing, distribution and logistics, and it is also what a plan sponsor uses to pay group health premiums. The 835 is healthcare only, sent by a health plan to a provider, and it carries adjudication detail an 820 has no concept of. If your file explains why a claim line was denied, it is an 835.
Often the 820 and the money are the same transmission. A NACHA CTX entry, the corporate trade exchange format, supports up to 9,999 addenda records of 80 characters each, and X12 remittance data is exactly what that space was built to carry. So a supplier can receive one ACH credit with the full 820 riding inside it, which is why BPR05 carries a payment format code of CTX or CCP.
In practice you meet the remittance in one of three shapes. Your bank unwraps the CTX addenda and hands you a clean 820 file. Your bank hands you the raw ACH file and you extract the addenda yourself, which the NACHA file to Excel converter and the walkthrough on how to open a NACHA ACH file in Excel both cover. Or the customer emails a remittance PDF and there is no EDI at all, in which case the bank statement converter turns that document into the same structured rows.
An 823 is what your bank sends back when it operates a lockbox for you. Customers mail checks to a PO box the bank controls, the bank opens, scans and deposits them, and then transmits the detail so you can apply the cash. One 823 can cover a single payment or an entire day of deposits, and banks typically send it on a schedule at end of day.
It matters because lockbox banks do not all speak the same dialect. Some send 823, some send BAI or BAI2, and some send a proprietary layout. If yours sends balance reporting rather than remittance, the BAI to Excel converter reads those files, and the bank file format converter compares the formats side by side so you can tell what you are holding. For check issuance going the other direction, the positive pay file format reference covers the file you upload for fraud matching.
Use a parser that understands X12 loops, then export one row per RMR item. Doing it by hand means reading the ISA envelope to find the delimiters, splitting on the segment terminator, and rebuilding the loop hierarchy so payment level facts attach to each invoice line. The converter at the top of this page does that in your browser and gives you a CSV. The alternative is a full EDI translator, which is the right answer if you are receiving 820s continuously and mapping them into an ERP, and overkill if you just need to read the file in front of you.
Once the rows are in a sheet the work is ordinary. Sum the amount paid per payment and check it against BPR02, sort by adjustment reason to find your recurring deductions, and pivot by customer to see who is short paying. Teams that push the result into accounting can map it through the NetSuite bank statement converter or the SAP bank statement converter, and the tie out itself is covered in bank statement reconciliation. If chasing the invoices behind these payments is the real problem, accounts receivable automation handles the follow up, and the outbound side of the same workflow is what accounts payable automation exists for.
EDI 820 is the ANSI ASC X12 transaction set named Payment Order/Remittance Advice. It either instructs a bank to pay a payee, tells a payee which invoices a payment covers, or does both in one file. The payment sits in a BPR segment and the invoice detail sits in repeating RMR segments underneath it.
It is used to pay suppliers and explain the payment at the same time. A buyer sends an 820 to its bank as a payment order, or straight to the supplier as a remittance advice listing each invoice paid, any discount taken, and any deduction. Plan sponsors also use the 820 to pay group health insurance premiums.
The 820 comes from the party making the payment and describes a payment it is sending. The 823 comes from your bank's lockbox service and describes payments the bank received and deposited for you. Both carry remittance detail in RMR segments, so both convert to the same kind of invoice level spreadsheet.
Industry and detail. The 820 is a general purpose remittance used across retail, manufacturing, distribution and logistics. The 835 is healthcare only, sent by a health plan to a provider, and carries claim level adjudication and denial reasons that the 820 has no equivalent for.
BPR is the Beginning Segment for Payment Order/Remittance Advice, and it holds the payment itself. BPR02 is the total amount, BPR03 flags credit or debit, BPR04 gives the method such as ACH, CHK or FWT, and BPR16 is the effective date. The routing and account numbers for both sides sit in between.
ADX is the adjustment segment. It explains money the payer deducted rather than paid: ADX01 is the adjustment amount and ADX02 is a coded reason such as a shortage, a pricing dispute, or damaged goods. When a paid amount is less than the invoice amount and no discount explains it, the ADX segment is where the answer is.
CTX is a payment format code that appears in BPR05. It means the remittance travels inside the ACH payment itself, as addenda records on a NACHA corporate trade exchange entry. A CTX entry supports up to 9,999 addenda records of 80 characters each, which is enough room to carry a full X12 820.
It is plain text, so any text editor opens it, but the whole file is usually one line because segments end with a tilde rather than a line break. To read it as data, run it through an X12 parser that rebuilds the loops. The converter on this page does that in your browser and returns one row per invoice.
Convert the ACH file that carries the payment.
Convert bank BAI2 balance reporting files.
Compare bank file formats side by side.
Cancel anytime from your account settings · refund policy
Get started converting bank statements to spreadsheets.
USD
per month
billed as
$288 yearly
Choose speed vs accuracy when extracting
| Base AI Faster | 2,500 pages |
| Pro AI Best accuracy | 500 pages |
Scale statement conversion across your team with automation.
USD
per month
billed as
$888 yearly
Choose speed vs accuracy when extracting
| Base AI Faster | 10,000 pages |
| Pro AI Best accuracy | 2,000 pages |
Enterprise-grade bank statement conversion and controls.
USD
per month
billed as
$ yearly
Choose speed vs accuracy when extracting
| Base AI Faster | pages |
| Pro AI Best accuracy | pages |
