Most accounts payable systems were built around one document: the invoice. It arrives, it is matched, it is approved, it is paid. When a supplier sends a credit note instead — a credit memo, in the vocabulary of most US ledgers — the tempting shortcut is to treat it as the same document with a minus sign in front of the total. Capture it, negate the amount, post it, and let the vendor balance sort itself out.
That shortcut works on the easy case, where one credit cancels one unpaid invoice in full. It fails on almost every other case, and it fails quietly. The open balance still adds up, so nothing looks wrong. What goes wrong is the question the ledger can no longer answer: which invoice was reduced, by how much, and why.
A credit note is its own document with its own grammar. It carries its sign in its type rather than in its numbers, it points at something that happened earlier, and it often points there only loosely. Reading it well means extracting those three things as facts, and leaving the decision about where the credit lands to rules the business owns.
The sign lives in the document type, not the amount
The clearest statement of this comes from structured e-invoicing, where the rules had to be written down. The Peppol BIS Billing 3.0 specification, which implements the European standard EN 16931, defines two ways to correct an invoice. One is a credit note, a separate document whose type code is usually 381. The other is a negative invoice: an ordinary invoice, type code 380, whose totals are below zero.
The specification is explicit about how the two differ. When crediting by means of a credit note, it says, the function of crediting or debiting is controlled merely by the business document type, and the representation of the amount, including its sign, is not affected. A credit note for 500 euros says 500, not minus 500. The document type is what turns that 500 into money flowing back to you.
That has an uncomfortable consequence for the negate-the-total shortcut. If a credit note is classified correctly and the pipeline also flips the sign, the credit is applied twice in the wrong direction. If it is misclassified as an invoice, a positive amount is posted as a new payable. And because a credit note can itself contain a line with a negative quantity, which re-debits something, a pipeline that negates every amount on a credit note turns that line into a credit as well.
| Document received | Type code | How its amounts are written | Effect on what you owe |
|---|---|---|---|
| Commercial invoice | 380 | Positive totals | Increases the payable |
| Negative invoice | 380 | Negative grand total | Reduces the payable, through the sign |
| Credit note | 381 | Positive totals | Reduces the payable, through the type |
| Credit note with a negative line | 381 | Positive total, one line below zero | That line adds back to the payable |
| Credit note balancing a negative invoice | 381 | Negative grand total | Increases the payable |
The last row is not a curiosity. The specification requires the credit note format to accommodate a negative grand total precisely because an entire negative invoice may have to be balanced out by a credit note. It also says that sending systems may choose either correction method while receiving systems have to support both. A buyer does not get to pick the convention its suppliers use.
Paper and PDF credit notes follow no specification at all. Some print positive amounts under the heading “Credit note.” Some print negative amounts under the same heading. Some print negative amounts under the heading “Invoice.” The extraction cannot resolve that by normalising the sign. It has to capture the document class, the amounts exactly as printed and the heading that justified the class, and let a single rule downstream decide what the combination means.
A credit applies to something
An invoice stands on its own: it claims a payment for goods or services. A credit note almost always refers to an earlier claim that it reduces. In the structured format, that reference is a named business group, BG-3 Preceding invoice reference, which carries the number of the original invoice and, where the number alone is not unique, its issue date. A single credit note may repeat the group to refer to several invoices.
The reference is what makes the credit applicable. Posting a credit note as a standalone negative line on the vendor balance reduces the total owed without reducing any particular invoice, which leaves the original invoice open and due. On the next payment run it is paid in full, and the credit sits unused on the account until someone notices. Nothing failed, and the supplier has been overpaid.
What the credit should do depends on the state of the invoice it refers to, and that state is not on the credit note. It lives in your ledger. That is why the application belongs to a rule rather than to the extraction.
| What the credit note says | State of the origin invoice | How the credit is applied | What the record must keep |
|---|---|---|---|
| One invoice, full amount | Open | Closes the invoice at zero | Credit and invoice linked, both closed |
| One invoice, partial amount | Open | Reduces the open balance; the invoice stays due | Remaining balance and the reason for the credit |
| One invoice, any amount | Already paid | Becomes a balance in your favour, offset against a future invoice or refunded under your policy | The paid invoice, the credit and the chosen settlement |
| Several invoices | Mixed | Allocated per referenced invoice | Amount per invoice; if the note does not state it, a review task |
| A period, not an invoice | Many invoices | Allocated by agreement, for example a volume rebate | The period, the note text and the allocation basis |
| No reference at all | Unknown | Held for matching; not applied | The candidate invoices and why each was proposed |
Partial credits and credits across several invoices
A partial credit is the ordinary case, not the exception. A supplier invoices seven days of work and then credits three that were not delivered; a shipment of 100 units arrives with 4 damaged and the supplier credits 4. The origin invoice stays open for the remainder, and the credit only makes sense next to it. If your approval workflow treats the invoice as closed once any credit is linked, the remainder never gets paid, and the supplier’s next statement shows an overdue balance your ledger does not.
The line-level detail matters here. A credit that says “3 days, consulting, at 400” can be matched to the line on the invoice it corrects, which keeps the quantity and price history intact. A credit that says only “adjustment, 1,200” can be applied to the invoice total but tells you nothing about which line was wrong. Both are valid; they carry different amounts of evidence, and the record should show which one you had.
When one credit refers to several invoices, the note may or may not say how much belongs to each. If it does, the extraction should keep the split exactly as printed. If it does not, the allocation is a decision, and it should be taken by a person or by a documented rule, not by an extractor that spreads the amount evenly because the numbers happened to divide.
The structured format also allows a credit that refers to no single invoice at all. Where a correction applies to a large number of invoices, the specification allows the invoicing period, BG-14, combined when necessary with a clarifying note, BT-22, to be given at document level instead. That is how volume rebates and year-end adjustments usually arrive: a period, a total and a sentence of explanation. It is a legitimate credit that has, by design, nothing to match against line by line.
The credit that names no invoice
Then there is the credit note that references nothing, which in paper and PDF form is common. A supplier sends “Credit note CN-2291, returned goods, 1,840.00” with no invoice number, no order number and no period. The amount is clear, the supplier is clear, and the destination is not.
The tempting rule is to apply unreferenced credits to the oldest open invoice from the same supplier. It reduces the backlog and it is wrong often enough to matter. If the supplier has two open invoices and the returned goods came from the newer one, the older invoice is now under-paid on the next run and the newer one over-paid, and the supplier’s reconciliation will disagree with yours on two documents instead of one.
A better pattern keeps matching and application apart. The extraction proposes candidates and shows its working:
- Amount — an open invoice, or a set of its lines, whose value equals the credit or a plausible part of it.
- Lines and items — the same item codes, descriptions or unit prices appearing on the credit and on the candidate invoice.
- Order and delivery references — a purchase order, delivery note or return authorisation printed on the credit that also appears on the candidate.
- Timing — a candidate issued before the credit, within a window your team sets and records.
A reviewer then confirms one candidate, splits the credit across several, or asks the supplier. Once confirmed, the application follows the same rules as a referenced credit. The difference is that the link was established by a person with evidence in front of them rather than inferred silently, and the record says so.
A credit can cross a period
An invoice issued in March and credited in May puts two dates in front of your accounts: the date of the original charge and the date of the correction. The credit note will usually print only its own issue date, and the date of the invoice it corrects if it references one at all.
Which period the adjustment belongs to, and how any tax on the original invoice is corrected, is decided by accounting policy and by the rules of the jurisdictions involved. It is not something an extraction pipeline should infer, and it is not something this article can settle. What the extraction owes that decision is completeness: the credit’s own issue date, the referenced invoice number and date, the tax amounts and rates exactly as printed on the credit, and a flag when the referenced invoice sits in a period your team has already closed. With those facts, the posting rule has what it needs. Without them, someone will reconstruct the dates from email threads at quarter end.
Not every credit is the same kind of credit
The structured format carries more than one credit note type, and the differences change what matching is even possible. The code list used by the specification includes, among others:
- Credit note related to goods or services (
81) — a correction to a supply. It should match an invoice line, and often a return or a short delivery. - Credit note related to financial adjustments (
83) — described as credit information about financial adjustments, bonuses for example. There are no goods behind it, so trying to match it to a goods receipt or a purchase order line will always fail. - Factored credit note (
396) — a credit note related to assigned invoices. The invoice it corrects was assigned to a third party, so the party you settle with may not be the supplier. That is a question for treasury, not for the matching rule.
All three can be processed as an ordinary credit note by a receiver that has no separate flow for them. That is the point of the synonym column in the code list. But the type is worth keeping even when it is not acted on, because it explains later why a credit never matched anything, or why a payment went to someone other than the supplier.
Classify before you extract
Everything above depends on the document being recognised as a credit note in the first place, and that is where a surprising number of errors begin. A credit note from a supplier whose invoices you process every week looks almost exactly like one of those invoices: same logo, same layout, same table. The heading changes and perhaps a reference field appears. The multi-agent back-office article uses exactly this as its example of poisoned context: a credit note labelled as a freight invoice, extracted with the freight schema, and passed by a validator whose rules are internally consistent.
So the credit note needs to be its own class, with its own schema, decided before extraction begins. The classification documentation lists credit_note alongside invoice among the finance classes a tenant can define. The signals that justify the class should be kept with the result: the printed heading, a preceding invoice reference, a type code on a structured document, and the sign convention of the totals. A negative total under the heading “Invoice” is a negative invoice, not a credit note, and both are allowed. What is not allowed is for the pipeline to forget which one it saw.
What the extraction has to deliver
The contract between the credit note and the application rule is a set of facts with evidence, and no decision about where the money goes.
- The document class and its evidence — credit note or negative invoice, the type code if the source is structured, and the heading or field that justified the class.
- Amounts exactly as printed — totals, tax and every line, with their printed signs, and no normalisation applied at extraction time.
- Every reference it carries — preceding invoice numbers and dates, purchase order, delivery or return references, and an invoicing period with its explanatory note.
- The split, when stated — the amount the note assigns to each referenced invoice or line, kept as printed; blank kept as blank.
- The credit note type — goods, financial adjustment, factored or unspecified, so the matching rule knows what it can expect to find.
- A citable origin for each value — page and region under the same coordinate contract any reviewable extraction owes, so a reviewer can go from a proposed match straight to the line that suggested it.
On the other side of that contract sit the application rules, the matching window, the settlement policy for credits against paid invoices and the posting rules for closed periods, all owned by the business and all versioned. A finding then reads as a sentence someone can act on: “credit CN-2291 names no invoice; two candidates share the return authorisation; held for review.”
Not three-way matching, not the e-invoicing queue
Two neighbouring problems touch the same documents and should stay separate from this one.
Three-way matching compares an invoice with a purchase order and a goods receipt, line by line, inside a tolerance. The three-way matching article covers why the line is the unit of truth and why tolerances must stay visible. A credit note enters that picture after the fact: it corrects an invoice that may already have matched, and its own line may have no receipt behind it at all.
Structured e-invoicing makes the syntax of a credit note reliable but leaves the business decision open, which the e-invoicing exceptions article treats as a cross-document problem. A perfectly valid 381 can still refer to an invoice you already paid or to one you never received, and that is where it needs the same exception path as everything else.
Read the type, then find the invoice
A credit note looks like the simplest document in accounts payable because it seems to ask for nothing: no approval chain for a payment, no goods to receive. In practice it asks the hardest question the invoice never did, which is where it belongs.
So classify it as its own document before extracting anything. Take its sign from its type and its amounts exactly as printed, and never negate twice. Extract every reference it carries, and treat a missing reference as a matching task rather than permission to guess. Keep the credit type, the dates and the stated split, and leave application, settlement and period to rules the business owns. The credit note will then do what it was issued to do: reduce one specific claim, by a specific amount, for a stated reason.