EDI 820 – Payment Order and Remittance Advice - part 2

Free Floating Adjustments

What we covered previously in this blog (see part 1) is the payment application information in the 820 associated with existing invoices or credits open in your AR System. You may also encounter what I call “free floating adjustments.” Deductions or credits completely independent of the invoices or anything else associated with the particular payment the 820 refers to. Let’s examine a common scenario.

Say your customer received and paid for a shipment last month. A shortage or damage situation was found with the shipment, or perhaps, the merchandise isn’t selling well and your customer is entitled to a promotion allowance. In these cases, your EDI 820 will likely contain a credit line item, with a reference number generated by your customer’s ERP. If you’re lucky, a valid invoice number or PO number might be embedded in the generated number, like CB12345, where 12345 is your invoice number and CB is a prefix designating a chargeback. Sometimes, unfortunately, it may just be an arbitrary number, meaningful only to your customer.

In a good EDI implementation, free floating adjustments like this will contain a reason code, but sometimes, your only recourse to find out what’s really going on requires you to login to a chargeback portal and enter the adjustment’s reference number to get the information you need. In any case, since you need to balance the payment to fully apply it, your only option is to accept these free floating adjustments into your AR, capturing as much information as you can from the 820. When importing these new transactions, your system will likely assign a newly generated reference number rather than the reference number sent with the 820. Be sure to have your import routines save the 820 reference number in an unused field for quick online access. You will definitely need it.

Potentially Helpful Technical Details

In this blog, I’ve implied that each invoice or credit comes in on its own “line” in the 820 with a set of fields determined by a particular customer’s implementation. It’s not that simple. All EDI transactions are made up of a set of segments, some global, and some specific to the transaction set. These segments are then woven together in “loops” structured in a predefined hierarchy. Recall the typical and optional adjustment information sent in an 820 at the remittance detail (vs payment) level.

Typical Information

• Document Type (invoice, credit memo, etc.)
• Reference Number
• Gross Amount
• Net Amount

Optional Adjustment Information

• Discount taken
• Adjustment amount
• Adjustment reason code

The typical information will be communicated in the RMR segment, officially named “Remittance Advice Accounts Receivable Open Item Reference.” Depending on your customer’s implementation, the RMR segment might also contain adjustment information. Alternatively, adjustments could also be contained in the ADX (Adjustment) segment. Per the EDI spec, the ADX segment is where payer generated free floating debits and credits should be communicated.

ADX Information

• Document Type (debit, credit, etc.)
• Reference Number
• Adjustment Reason Code
• Adjustment Amount

There are also less common segments, like the SAC segment for “Service, Promotion, Allowance or Charge Information.” And there are ample provisions for including free form text comments if your customer chooses to use them.

My point in going to this level of detail is to make you aware of what you may be missing. Your EDI department or supplier may not be mapping all the populated segments and fields for a given customer implementation. Your technical folks will often follow a “copy and paste” implementation strategy basing a new implementation on that of similar existing customer. This makes it easier to miss an uncommon segment, field or comment that might be very helpful for cash application and collections.