Why You Can't Use Negative Amounts on a Peppol Credit Note

If you have ever created a credit note, you probably wrote negative amounts. That is how it worked on paper. A €500 invoice had an error? You issued a credit note for −€500. The minus sign told your accountant what to do. Simple, intuitive, universal.

Then you switch to Peppol e-invoicing, send your first credit note with negative amounts, and it gets rejected. Welcome to the world of structured e-invoicing, where machines need precision, not convention.

The paper era: negative amounts were a visual cue

For decades, credit notes used negative amounts as a human-readable signal. When an accountant opened a paper credit note and saw −€500, the meaning was instant: subtract this from the customer's balance. The document title said "credit note" and the negative number reinforced the message.

This worked because a human was always in the loop. The accountant understood the context, knew what a credit note meant, and interpreted the negative sign accordingly. There was no strict rule. Some businesses used positive amounts on credit notes (the document title was enough context). Others used negative amounts. Both were accepted because the human reader could figure it out.

The problem: machines don't "figure it out"

In structured e-invoicing, there is no human in the loop. A Peppol e-invoice is an XML/UBL file processed entirely by software. The receiving system reads the document type, the amounts, the tax calculations, and books everything automatically. There is no accountant squinting at a minus sign to decide what to do.

This is where ambiguity becomes dangerous. If a credit note has negative amounts, does the receiving system negate the already-negative amounts (because it knows this is a credit)? Or does it take the amounts at face value? The answer depends on the software, and different interpretations lead to different financial outcomes. One system might book −€500. Another might book −(−€500) = +€500. That is a €1,000 difference.

How Peppol handles credit notes

The Peppol BIS Billing 3.0 specification is explicit about this. It states: "The function of crediting or debiting is controlled merely by the business document type (e.g. 380 or 381) while the representation of the amount, including its sign, is not affected."

In plain language: the document type tells the system what to do with the amounts. You do not need to duplicate that information by changing the sign.

Both approaches produce the same financial result. The choice depends on your accounting system's preference. But you cannot mix them. You cannot use document type 381 (credit note) and also use negative amounts. That would be telling the system twice, in two conflicting ways, that this is a credit.

What the XML looks like

Here is a simplified example of a correct Peppol credit note. Notice that all amounts are positive:

<!-- Credit Note (type 381) - amounts are POSITIVE -->
<CreditNote xmlns="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2">
  <ID>CN-2026-001</ID>
  <IssueDate>2026-03-10</IssueDate>
  <CreditNoteTypeCode>381</CreditNoteTypeCode>

  <!-- Reference to the original invoice being credited -->
  <BillingReference>
    <InvoiceDocumentReference>
      <ID>INV-2026-042</ID>
    </InvoiceDocumentReference>
  </BillingReference>

  <CreditNoteLine>
    <ID>1</ID>
    <CreditedQuantity unitCode="EA">5</CreditedQuantity>
    <LineExtensionAmount currencyID="EUR">500.00</LineExtensionAmount>
    <Item>
      <Name>Consulting hours (March)</Name>
    </Item>
    <Price>
      <PriceAmount currencyID="EUR">100.00</PriceAmount>
    </Price>
  </CreditNoteLine>

  <LegalMonetaryTotal>
    <TaxExclusiveAmount currencyID="EUR">500.00</TaxExclusiveAmount>
    <TaxInclusiveAmount currencyID="EUR">605.00</TaxInclusiveAmount>
    <PayableAmount currencyID="EUR">605.00</PayableAmount>
  </LegalMonetaryTotal>
</CreditNote>

Every amount is positive. The CreditNoteTypeCode of 381 and the use of CreditNoteLine elements tell the system this is a credit. No ambiguity.

Compare this with how you would send the same credit as a negative invoice:

<!-- Negative Invoice (type 380) - amounts are NEGATIVE -->
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <ID>INV-2026-043</ID>
  <IssueDate>2026-03-10</IssueDate>
  <InvoiceTypeCode>380</InvoiceTypeCode>

  <BillingReference>
    <InvoiceDocumentReference>
      <ID>INV-2026-042</ID>
    </InvoiceDocumentReference>
  </BillingReference>

  <InvoiceLine>
    <ID>1</ID>
    <InvoicedQuantity unitCode="EA">-5</InvoicedQuantity>
    <LineExtensionAmount currencyID="EUR">-500.00</LineExtensionAmount>
    <Item>
      <Name>Consulting hours (March)</Name>
    </Item>
    <Price>
      <PriceAmount currencyID="EUR">100.00</PriceAmount>
    </Price>
  </InvoiceLine>

  <LegalMonetaryTotal>
    <TaxExclusiveAmount currencyID="EUR">-500.00</TaxExclusiveAmount>
    <TaxInclusiveAmount currencyID="EUR">-605.00</TaxInclusiveAmount>
    <PayableAmount currencyID="EUR">-605.00</PayableAmount>
  </LegalMonetaryTotal>
</Invoice>

Same financial outcome. Different mechanism. With a negative invoice, the negative amounts carry the meaning. With a credit note, the document type carries the meaning. Pick one, not both.

Validation rules that enforce this

Peppol does not rely on good intentions. The network enforces rules through automated validation. If your credit note contains negative amounts, it will be rejected before it ever reaches the recipient.

The key validation rules from EN16931 and Peppol BIS 3.0 include:

When your access point validates the document against these rules, a credit note with negative line amounts or a negative unit price will fail. The document never enters the Peppol network. You get an error, and the recipient gets nothing.

Why this is actually better

The old paper way was ambiguous. Different countries, industries, and even individual companies had different conventions. Some used negative amounts on credit notes. Some used positive amounts. Some even mixed both in the same document. Accountants dealt with this by using professional judgment. They looked at the document as a whole and figured out what was intended.

In automated processing, professional judgment does not scale. When thousands of invoices per day are processed automatically, every document must be unambiguous. The Peppol approach gives every document exactly one way to convey its meaning:

• Credit note (381) = positive amounts, document type indicates credit
• Negative invoice (380) = negative amounts, sign indicates credit

No overlap. No ambiguity. No room for interpretation. This is what makes fully automated invoice processing possible at scale.

How to fix your credit notes

If your accounting software currently generates credit notes with negative amounts, you have three options:

Which approach should you use?

Peppol BIS 3.0 supports both credit notes (381) and negative invoices (380). Invoice-receiving systems are required to accept both. So from a technical standpoint, either works.

In practice, the dedicated credit note (type 381) is the more common and recommended approach. It is clearer in intent, aligns with EU standard EN16931, and is the default for most accounting software. Negative invoices are mainly used by organizations that have legacy systems that cannot generate proper credit notes.

Whatever approach you choose, the rule is simple: do not mix the two. Use positive amounts with type 381, or negative amounts with type 380. Never negative amounts with type 381.

A quick reference table

Bottom line

The shift from paper to Peppol e-invoicing requires a mindset change. Negative amounts on credit notes were a visual convention for humans. In structured e-invoicing, the document type carries the semantic meaning. Amounts stay positive on credit notes because the document type 381 already tells the system to credit.

It is more precise. It is mathematically unambiguous. And it is the only way that works when machines process thousands of documents without human intervention. The paper convention had its time. Peppol is the upgrade.

Frequently asked questions