You counted five cartons on the loading dock. Then you get to the unit box next to the quantity on the invoice and there is no option that says "carton". The unit code lists you find online do not answer the question either: they all copy the same table and stop where the table stops. The answer you want is not inside that table — it is in the field next to it.
The argument fits in one sentence: a box is not a unit of measure, it is a container. An electronic document asks "how much of the goods" and "in how many packages" as two separate questions; they are two different fields fed by two different code lists. You count cartons in the warehouse, but there is no code for a carton in the quantity unit. Forcing both into one field is how the number on the dock and the number on the document stop agreeing for good.
A box is not a unit of measure, it is a container
A document line carries two different numbers, and both are correct. The first is the quantity of the goods: sixty pieces, twenty-three kilograms, four hundred metres. Next to that number there is always a unit of measure, and that unit is not free text — it comes from a code list. The second is the packaging information: how many packages are the goods travelling in, and what kind of package? The package count and the package type have fields of their own, and the package type has a code list of its own.
That is exactly where the confusion is born. The language spoken in the warehouse is the language of packages — you say "five cartons went out", not "sixty pieces went out". The person filling in the document, however, is sitting in front of the quantity field, and there is no carton on the list in front of them. What happens next is almost universal: whatever looks closest gets typed into the unit box, and the packaging information is never filled in at all. The number counted on the dock ends up nowhere on the document.
So the right form of the question is not "which code does a carton map to" but "which field does a carton go in". Once you have found the field, the code question mostly answers itself. The remaining fields of the document — the parties, the number, the actual despatch date, the carrier — are covered separately: what a delivery note must include.
The unit next to the quantity: the list your format points at
Whichever electronic invoice format you are on, the unit next to the quantity is a code taken from a published list, and the format tells you which list. Peppol BIS Billing 3.0, for example, points at UN/ECE Recommendation 20. For Turkish e-documents the value is taken first of all from the unit code list published by the tax administration, and the guide says so in its own words: the value set is to be taken from that list first, and unit codes not on it come from two named fallbacks. The version current on the day this article was written is UBL-TR (Kod Listeleri), July 2026, version 1.43 (the administration's e-document guides). The version matters: this guide changes several times a year, and a copied list with no date on it is worth nothing.
There is no point dumping the list here in alphabetical order; that has been done eight times over. Look at it by function instead, because the question asked in a warehouse is not "which letters exist" but "which group does the thing I sell fall into":
| What is the unit answering? | What the list carries |
|---|---|
| Countable wholes — how many? | The code for a single piece is C62 — on Peppol's own code list its entry reads "One (synonym: unit)". The same list also carries codes for pairs, sets, hundreds and thousands of pieces, so selling in multiples is already covered. |
| Measured quantities — how much? | Kilograms, grams, litres, metres, square metres and cubic metres each carry their own code on the same list. What this group has in common is that its values can be fractional. |
| Packages — cartons, boxes, pallets? | This group is not on this list at all. The package type is written into a separate field from a separate list — the subject of the next section. |
Selling in a unit that is not on the list?
Tonnes, millilitres, centimetres, linear metres — some of the units used every day in a warehouse are simply not on the national list, and this is where most people get stuck. But "not on the list" is not a dead end; it is the second step the guide itself prescribes. The Turkish guide says it plainly: unit codes not present in its list are to be taken from the UN/ECE unit codes and from a ministry-published EDI/XML measurement unit list. The door is not closed, it just opens onto a second address.
One caution. The guide's footnotes point at specific files of those international lists, but this article does not state which revision of those standards is current today — we could not verify that at source, and an unverified version number does more damage than no list at all. The practical route: open the file the footnote names and look your unit up there yourself. Then write down the code together with the date and the file you took it from. Two years later, the answer to "why did we pick this code" will exist only in that note.
Package type is a separate list: box, carton, crate, sack
What the goods are travelling in is not written where the quantity unit goes; it goes in a field of its own. In UBL-TR that field is called PackagingTypeCode and it has its own code list: BX for a box, DK for a carton crate, CR for a crate, CH for a chest, CN for a container, SA for a sack, BG for a bag, NE for goods sent unpacked.
Now the point that matters: there is no code for "carton" as a single generic thing here either. The two nearest matches are the box and the carton crate, and choosing between them is a decision, not a translation. Make the decision once and let everyone use the same code afterwards. The question to settle is whether the thing you call a carton is specifically a cardboard container, or your generic word for any outer packaging whatever it is made of. If it is the first, the carton entry is the more consistent choice; if the second, the box entry is. Both are defensible; what is not defensible is a different code on every document.
The package list is not a closed one either: for package types that are not on it, the guide points to the UNECE/CEFACT package and container list. The same logic as on the unit side applies here — its own list first, then the international one.
A warning as well: this question has a widely circulated answer online, and the code in that answer appears on neither of the two lists. We are not repeating it here, because repeating it spreads it one step further. The verification method is simple: when you hear a code, search for it in the guide's own PDF. If it is not there, it does not exist, whoever said it.
How many cartons went out is usually nowhere on the document
The two sections above told you where the fields are. Here comes the most practical finding in this article: filling those fields in is not mandatory. In the UBL-TR common elements guide, the package element's number, package count and package type are all defined as optional; so is the total package quantity on the transport handling unit. Source: UBL-TR Ortak Elemanlar, April 2017, version 0.7.
What an optional field means in practice is this: a field your provider does not populate stays quietly empty. Nothing errors, nothing warns, the document is valid. It just says "sixty pieces". The five cartons counted on the dock appear nowhere — not on the document, and not on the copy the other side reads. For the receiving bay to be able to say "we were expecting five cartons", they must have learned that five from some other piece of paper.
The to-do list that follows is short but it works. One: open the raw form of one of your own documents and look at whether the package count field is populated. Two: if it is, look at which code it carries. Three: if it is empty, write down by which other route that number reaches the customer. All three take half an hour, and you never have the "why isn't the carton count on the document" argument again.
The unit you count in does not have to be the unit you declare
Most people who have read this far are asking one thing: "if I count cartons in the warehouse, what do I hold in my system?" The answer is reassuring: the two do not have to match. The warehouse unit and the document unit are two separate realities and each has its own good reason. The dock counts packages because packages are what it handles; the document declares goods because goods are what has a measure.
What matters is who does the conversion between them, and when. Somebody performs that conversion sooner or later: either it is done once on the item record and applied automatically to every document, or it is done in someone's head on every shipment. The second works for the first ten shipments; on the eleventh a different person steps in and works it out differently. Write the rule down: the conversion lives on the item record, not on the document.
Why the unit is a coded field rather than free text, why discrete and fractional units travel in pairs, and how that is set up on an item record are covered separately; if you are building this from scratch, start there: fixing units during the migration.
The rule is different abroad: a package code can be a unit code
Does the same separation hold on an invoice going abroad? No — and this is where integrators most often get it wrong. The code list Peppol BIS Billing 3.0 uses for the quantity unit is named, word for word: "Recommendation 20, including Recommendation 21 codes - prefixed with X (UN/ECE)" (docs.peppol.eu). Which means that there, package codes — prefixed with X — can be used directly as unit codes.
On the logistics side Peppol's package code list carries CT for a carton, BX for a box, PX for a pallet, CR for a crate and CS for a case (docs.peppol.eu). The same word ends up in two different places in the two systems: in Turkey the package code sits in a separate field, unprefixed, while on the Peppol side it can sit as the unit of the quantity, prefixed. If you are wiring an integration to both, write that difference down — the same letters mean different things in the two places.
The general lesson: there is no single universal "unit code" field. Which code list applies is decided by the format you send in and the administration you send to. Seeing a code in one place and carrying it into another is the common source of every confusion described in this article.
The guide's own example does not match its current list
There is an interesting inconsistency inside the same guide package, and knowing about it explains at a stroke why you sometimes see a different code. The current version of the code list guide gives C62 for a piece. The sample XML in the despatch advice guide from the same package, dated 2018, shows NIU as the quantity unit instead (UBL-TR Sevk İrsaliyesi, December 2018, version 1.2). Two documents, two different codes.
This calls for care, because it is easy to draw the wrong conclusion from it. This article only reports what the two documents say. We are not concluding that the older code is now invalid, that the administration would reject it or that a service provider would error on it — none of that appears in the primary sources we have, and an unsourced verdict does more damage than the code itself.
The one practical lesson worth taking is this, and it is worth enough: the code list guide is what binds, not the sample XML. Before copying a code you saw in an example, look it up in the current code list. And remember that the guide version changes several times a year — a copy that was right three years ago may not be right now. Keeping a note of which guide version the codes in your integration came from stops this question from being asked twice.
Where a wrong mapping actually hurts
All of this can look like an accounting detail. It is not, because the same number is used in three more places in the warehouse. First, how many labels get printed: that follows from the package count, and if the count is wrong you end up with spare labels or unlabelled cartons. Second, the number of scans expected when loading by barcode: the system works out how many scans to wait for from the same relationship. Third, the agreement between quantity and carton count on the packing list. All three trace back to one decision, and that decision is the subject of this article.
We are not opening the three up here, because each has its own article. Which fields belong on the label is a design job of its own: which fields belong on a carton label. So is the way quantity and carton count are read together on a packing list: quantity and carton count on a packing list. If you would rather try a label right away, we have a tool that runs in the browser: carton label generator.
One shipment, three documents, three different numbers
Looking at three documents for one shipment and finding three different numbers is common, and most of the time all three are right, because they count different things: pieces of goods, packages, and pieces inside a package. Knowing which number belongs on which document removes most of what looks like a contradiction. That distinction, and the abbreviations the documents use for it, are covered separately: what CTNS and PCS are saying.
What we do on this side, and what we do not
We close this article with a boundary rather than a product pitch, because this is precisely a subject where the wrong expectation gets expensive.
What we do. In Smartifie Logistic the unit is not a free text box but a canonical code: piece, kilogram, tonne, gram, litre, millilitre, metre, centimetre, square metre, cubic metre, package, box, carton, pallet, roll, set, pair and kit. The code is data; the name you see on screen is presentation — the code does not change with the language. When importing from Excel you may write the unit name in any of the three interface languages and they all resolve to the same code; a row carrying a unit that cannot be resolved is not guessed at, it is skipped. For units that can take fractional values (kilogram, litre, metre and the like) a second unit and a conversion rate are mandatory. The unit screen at /units shows which codes are accepted and marks each as continuous or discrete.
What we do not do — and we would rather write it out. The application does not produce e-invoices. On the despatch side an XML file can be downloaded, but we do not sign it, do not validate it against the administration's schema and do not send it; those steps are outside the application's scope and the code itself leaves them to a later phase. That is why this article shows no sample of the XML we produce and makes no claim that we write the codes correctly. There is also no packaging type field in the application, and no tool that checks unit codes against the official list. The confusion this article describes is a widespread one, and the honest answer is that our own side is not outside it.
To close on the opening argument: a box is not a unit of measure, it is a container. The document asks two questions, has two fields and draws on two lists. Separate them once and "which code is a carton" stops being a hunt through a code list and becomes a choice of field — and that question is far easier to answer.