The six fields on a UBL invoice line that decide a price check

· Šis puslapis pateikiamas anglų kalba.

A UBL invoice line holds the price a buyer compares in one place: cac:Price/cbc:PriceAmount, the item net price, BT-146 in the European semantic model. Set beside the right column of a price list it answers the question; set beside the wrong one it invents a difference on every line of the document.

A gouache illustration of six flat paper slips pinned in a row above a workbench, one of them larger and in a warmer colour than the rest.

Price Double Check reads a structured invoice the way it reads a PDF and answers by email with the lines that disagree: the arithmetic is identical, only the retrieval differs. The fields matter because a mandate does not read them for meaning. Five of them stand around the price and decide what it means, and a value taken from the wrong element gives a confident wrong answer, which costs a reader more than no answer does.

The six fields, and where each one sits

What it isBusiness termWhere it sits on the line
The seller's item codeBT-155cac:Item/cac:SellersItemIdentification/cbc:ID
The item net priceBT-146cac:Price/cbc:PriceAmount
The quantity that price applies toBT-149cac:Price/cbc:BaseQuantity
The quantity billed, with its unitBT-129 and BT-130cbc:InvoicedQuantity and its unitCode
The line net amountBT-131cbc:LineExtensionAmount
Discounts and charges on the lineBT-136 and BT-141cac:AllowanceCharge on the line

The price is required on every line by the specification's own rule, which is already more than a PDF guarantees. The base quantity is optional, and that is the first thing worth knowing about it. So is the item's standard identifier, BT-157, which is where a barcode number would live and where a buyer would most like to find one — it is almost always absent.

The price is net, and that is the trap

BT-146 is the unit price after the item price discount has already been taken off. The gross price it was discounted from is a separate term, BT-148, and it sits inside cac:Price/cac:AllowanceCharge alongside the discount amount, BT-147. A supplier's price list quotes one or the other and rarely says which. Compare a net price on the invoice with a gross price on the list and every line becomes a finding, and a report in which every line is a finding is a report nobody opens twice.

The base quantity decides what one unit is

BT-149 states how many units the price covers. A price of 24.00 with a base quantity of 12 is two per unit; a line that omits the field means one. A list that quotes per case against an invoice that prices per bottle is the same problem wearing different clothes, and neither document announces it. Normalising both sides to a single unit is not an optimisation, it is the comparison.

The order to read a line in

  1. Read the seller's item code first and join on it. Descriptions do not survive the trip from a catalogue to an invoice: in the chain behind this service, 335 of 442 lines carried a description that did not match the price list's own wording for the same code, and matching on words would have failed on nearly all of them.
  2. Take BT-146 as the price to compare, not the line amount. The line amount has quantity and line-level discounts folded into it already.
  3. Divide by the base quantity before subtracting anything. Absent, treat it as one; present, bring the price list's own pack to the same unit.
  4. Check the unit of measure on the quantity. A line billed in cases against a list priced by the kilogram is not a price difference, and reporting it as one is a false alarm with a long memory.
  5. Recompute the line. The net price divided by the base quantity, times the invoiced quantity, less line allowances and plus line charges, should equal BT-131 to the cent.
  6. Add the lines up and set the sum against the document total before saying anything at all. Where that cent goes, and why a cent is a tolerance rather than a finding, is in the cent that is rounding and not an overcharge.

What the structure does not promise

A valid invoice is one whose form is correct. The specification checks that the price is present, that amounts carry no more decimals than they are allowed, and that the line adds up. It holds no opinion at all about whether the price is the price that was agreed. In the chain behind this service one line was billed 17.75 per cent above the newest list the buyer held, €47.76 on that line alone, and no validator in any format would have raised a word about it.

Document-level allowances are the companion gap. A discount sitting on the document rather than on the line never reaches BT-146, so a line can read at full price while the invoice total is perfectly correct; the four places a promotion goes missing are set out in a promotion that did not reach the invoice. Getting the file at all is a separate question, and one a small buyer can answer without software, as receiving Peppol invoices without an ERP goes through.

Trumpai

Which field to compare against a price list
The item net price, BT-146 at cac:Price/cbc:PriceAmount, divided by the base quantity in BT-149. That gives the per-unit price after the item discount, which is the number a price list's unit column is comparable with.
What a buyer needs in order to read a UBL invoice
The file, and a way to take six values out of each line. No ERP is needed for the reading itself; what an ERP adds is storage and workflow, and both can be had by forwarding the documents somewhere that keeps them.
Why a structured invoice still has to be checked
Validation is about form, not about agreement. An invoice can satisfy every rule in the specification and still carry a unit price nobody agreed to, which is the one thing only a comparison with the price list can show.

Forward one invoice and the price list it should have been billed on, in whatever form each of them arrived, and the comparison comes back by email line by line. What it costs and how the reply reads are on the home page.

Visi straipsniai