The EDI 812, Decoded: A Credit/Debit Adjustment Is How a Deduction Stops Being an Argument

The EDI 812 · Credit/Debit Adjustment is how a trading partner tells you, in structured form, that the amount on an invoice is not the amount they intend to pay — and exactly why. It does not pay anything and it does not correct your invoice. It documents the claim: which invoice, which direction (credit or debit), which reason, and how much.

That sounds like bookkeeping trivia until you have lived through a deduction. A retailer short-pays an invoice by $412, the remittance advice shows a reason code, and finance is left arguing from screenshots and memory about whether the shortage was real, whether the price was wrong, or whether the shipment was late. The 812 exists to move that argument into data both systems can match, dispute, or accept — before it hardens into an unrecoverable write-off.

What is the EDI 812 · Credit/Debit Adjustment?

The 812 is an X12 transaction set used to communicate or request an adjustment to a previously billed amount. Either side can send it: a buyer claiming a credit for a pricing error or a shortage, or a seller requesting a debit for an under-billed shipment.

Three ideas define it:

• It states a claim, not a verdict. Sending an 812 does not prove the adjustment is valid. It identifies the claim precisely enough that the other side can verify it against the original invoice, the shipment record, and the remittance.
• It is anchored to the original document. A useful 812 references the invoice it adjusts. An adjustment floating free of its invoice is just a number looking for an argument.
• It carries a reason, in code. Shortage, pricing discrepancy, damaged goods, late ASN, freight dispute — the reason code is what lets the receiver route the claim to the team that can actually resolve it, instead of a generic deductions inbox.

How is the 812 different from the 810, the 820, and the 997?

These four messages get confused constantly, and the confusion is expensive:

• The 810 · Invoice states what you billed in the first place.
• The 812 · Credit/Debit Adjustment states what one side says should change about that bill, and why.
• The 820 · Payment Order / Remittance Advice states what was actually paid, including any deduction taken.
• The 997 · Functional Acknowledgment only answers whether a file parsed. It says nothing about money.

A clean 997 on your 810 tells you nothing about whether you will be paid in full. The deduction story only becomes visible when you reconcile the 820 against the 810 — and the 812 is the document that explains the gap in structured form, when your partner sends one.

Where do 812 adjustments actually come from?

In practice, most adjustments trace back to a small set of causes:

Shortages and receiving discrepancies. The ASN said 100 cases, receiving counted 96. The buyer credits itself for the missing four. The fix upstream is rarely in accounting — it is in the accuracy of the 856 · Advance Ship Notice against what was physically packed.

Pricing mismatches. The invoice price does not match the price on the purchase order or in the item file. This is the most preventable category: it is a master-data problem surfacing as a finance problem, usually weeks after the order shipped.

Compliance chargebacks. Late or inaccurate ASNs, label errors, missed ship windows. Retailers deduct these under their compliance programs, and the adjustment documents the penalty. Whether you can dispute it depends entirely on whether your own records — timestamps, label scans, carrier data — are as structured as theirs.

Freight and allowance disputes. Freight billed differently than agreed, or a promotional allowance claimed twice. These need the original agreement terms matched line by line, not a phone call.

What breaks when teams handle adjustments badly?

The adjustment is posted without matching. Someone in finance posts the credit to clear the receivable, and the underlying shortage or pricing error never gets fixed — so it recurs on the next order, and the next. Posting is not resolving.

Nobody owns the reason codes. If deductions land in one undifferentiated bucket, you cannot see that 60% of your write-offs are one retailer's ASN timing rule. Aggregation hides the fixable pattern.

The dispute window closes. Most retailer programs give you a limited window to dispute a deduction with evidence. Teams that discover adjustments at month-end close have often already lost the right to argue, however good their evidence is.

The corrected-invoice question gets skipped. An 812 does not replace a corrected invoice where your partner's process requires one. Assuming the adjustment document settles the billing record — when the partner expected a re-billed 810 — leaves the accounts out of sync in the opposite direction.

How should you reconcile an 812 before posting it?

1. Match it to the original invoice. Every line of the claim should trace to a billed line. Anything that does not trace is a question, not a posting.
2. Compare it with the remittance. Does the deduction on the 820 equal the adjustment claimed on the 812? A mismatch between the two is itself a finding.
3. Verify the claim against your own evidence. Shipment records for shortages, the order and price file for pricing, transmission logs for ASN timing.
4. Decide explicitly: accept, dispute, or partially accept. Record the decision and the reason where the next adjustment from the same partner will find it.

That fourth step is the one that compounds. A log of accepted-versus-disputed adjustments, by partner and reason code, is how a deductions problem turns into a short list of operational fixes.

Frequently asked questions

Does an 812 move money?
No. It communicates or requests an adjustment. Money moves through payment — the 820 · Payment Order / Remittance Advice is where the actual deduction shows up.

Can a seller send an 812, or only buyers?
Both. A buyer commonly sends one to claim a credit; a seller can send one to request a debit, for example for an under-billed amount. Direction depends on who is asserting the change.

Is an 812 the same as a credit memo?
It is the EDI expression of the same business idea, but it is not automatically your accounting system's credit memo. Most teams map an accepted 812 into their ERP's credit or debit memo process rather than posting the EDI document directly.

What is the difference between an 812 and an 824?
The 824 · Application Advice reports errors found when a document was applied to a business system. The 812 asserts a financial adjustment to a billed amount. One is about document validity; the other is about money owed.

---

Adjustments are where EDI stops being a data-format conversation and becomes a margin conversation. The partners who handle them well are not the ones with the fewest deductions — they are the ones whose deductions arrive structured, get matched before they get posted, and feed back into the ASN, pricing, and packing processes that caused them.

I build SignalEDI to help SMB teams handle exactly this layer — validation before transmission, acknowledgments and adjustments reconciled against the original documents, so a deduction is a work item with evidence attached, not a surprise at month-end.

— Chris, founder of SignalEDI