# Negative invoice lines
> https://billhorse.com/en/guides/negative-invoice-lines/
## Where negative lines come from
Three cases come up again and again in practice. First, a **correction within the same invoice**: an item was entered twice or billed incorrectly and is reversed right below, instead of issuing a separate corrective invoice. Second, **deposits and returns**: returnable packaging or returned goods are offset against the next delivery — the return appears as its own line with a negative amount next to the new items. Third, **offsetting prepayments**: the final invoice lists all supplies and deducts previously invoiced down payments as negative lines.
The third case deserves a closer look: for amounts already paid, EN 16931 also provides the field [BT-113](/en/terms/bt-113/) (prepaid amount), which per [BR-CO-16](/en/rules/br-co-16/) is deducted from the gross total *after* VAT. A negative line, by contrast, acts *before* VAT and reduces the taxable amount. Which route is correct depends on whether the prepayment invoice already charged VAT — a tax question, not a technical one. Both routes are conformant.
## What the standard allows — and what it doesn't
The line net amount [BT-131](/en/terms/bt-131/) may be negative. The clean way to build it is: **negative quantity, positive price**. The invoiced quantity [BT-129](/en/terms/bt-129/) is explicitly signed — taking back one unit is simply `-1`. The item net price [BT-146](/en/terms/bt-146/), however, must **not be negative**: that is exactly what business rule BR-27 of EN 16931 says. Billhorse does not check BR-27 yet — but receiving systems and other validators (such as the KOSIT tool) do, and an invoice with a negative price gets rejected there. So never negate the price; always negate the quantity.
## A negative line in UBL and CII
In UBL, a return looks like this — negative quantity, positive price, with `LineExtensionAmount` following as quantity × price:
```xml
2
-1
-89.00
Return: charger
S
19
VAT
89.00
```
The same in CII (ZUGFeRD/Factur-X): the quantity sits in the delivery part as `BilledQuantity`, the price as `ChargeAmount` inside `NetPriceProductTradePrice`, and the line amount as `LineTotalAmount` in the line monetary summation:
```xml
2
Return: charger
89.00
-1
VAT
S
19
-89.00
```
## Allowance or negative line?
Not every deduction belongs in its own line. A **discount on one item** — volume discount, promotional price — is a line-level allowance ([BG-27](/en/terms/bg-27/)) with its amount in [BT-136](/en/terms/bt-136/); it stays part of the same line and reduces that line's BT-131. A **discount on the whole invoice** — loyalty rebate, agreed general reduction — is a document-level allowance ([BG-20](/en/terms/bg-20/), amount in [BT-92](/en/terms/bt-92/)) and feeds into the allowance total BT-107. A **negative line** is the right tool when you are modelling a transaction of its own, with its own quantity and its own item: a return, a deposit refund, an offset prepayment. Rule of thumb: if the deduction refers to a delivery of something, it is a line; if it is merely a pricing component, it is an allowance.
## The totals still have to add up
Negative lines change nothing about the standard's arithmetic — they are simply included in the sums. [BR-CO-10](/en/rules/br-co-10/) requires the sum of line amounts [BT-106](/en/terms/bt-106/) to equal the sum of all line net amounts (BT-131) exactly, negative values included. The chain builds on top of that: per [BR-CO-13](/en/rules/br-co-13/), the net total BT-109 = BT-106 − allowances (BT-107) + charges (BT-108), and per [BR-CO-15](/en/rules/br-co-15/), the gross total BT-112 = BT-109 + VAT (BT-110). Always compute these fields from the lines instead of maintaining them separately. If the sum of lines turns negative overall, that is formally permitted — but in most cases a credit note (type code 381) is the more appropriate document.
## VAT: the category has to match
A negative line carries the same VAT category and the same rate as the supply it corrects — the return of an item billed at 19% goes into category S at 19%, not into Z or E. The taxable amount of each category is the sum of its line amounts, so the negative line reduces the base of *its* category. Put it in the wrong one and the VAT breakdown (BG-23) and the rules of the BR-S family fall apart — up to contradictions like an exemption reason inside a taxed category ([BR-S-10](/en/rules/br-s-10/)), and the VAT total no longer satisfies [BR-CO-14](/en/rules/br-co-14/).
To see whether your invoice with negative lines passes, run it through the browser validator — the file never leaves your machine. To integrate the same engine into your own software, there is the [developer API](/en/api/) (private beta) with the validate and parse endpoints.