How UBL Represents Quantities, Unit Codes and Price Bases

Review the invoiced quantity, its unit and the price’s base quantity together. They determine how the charge should be understood. A price per hundred units is not a per-unit price, and a readable label such as box does not perform a conversion or supply a validated unit code.

The UBL preparation workflow preserves the agreed basis before generation. The current creator supports positive quantities, free-text units and a single price per entered unit. It has no dedicated price-base quantity or formal UBL unit-code mapping.

Establish the source basis

Use the accepted price agreement and delivery evidence. Identify what is counted or measured and how many of those units the quoted price covers. Do not combine a physical item count from one record with a box price from another without resolving the conversion.

For a fictional quote of 24.00 per hundred items, the base is one hundred items. Entering 24.00 as the price for each item would change the charge. The final representation needs to preserve the original basis or a justified equivalent supported by the target.

Keep the source record available so a reviewer can distinguish an intentional conversion from an accidental unit change. A label alone cannot establish that the numeric values were converted correctly.

Inspect the quantity unit

The target profile can require a coded unit tied to the invoiced quantity. Confirm the applicable list and exact meaning. A source word, local abbreviation or stock-system label is not automatically the required code.

Do not guess a mapping from the first letters of the label. A package, session and individual item can all be called unit in different businesses. Clarify the actual commercial meaning before assigning a formal value.

OpenPeppol’s invoiced-quantity documentation provides a specific coded-unit example. Apply its requirements in the intended profile context rather than claiming every free-text unit entered in the creator already implements that binding.

Inspect the price group

The published UBL price binding distinguishes item price and price-base quantity roles. A mapper must preserve their relationship according to the target rules. Copying a rate into a field named price is insufficient if its base is lost.

Use the line-tracing process to inspect the quantity and price in their actual line context. A document can contain all the expected numbers while associating the base with the wrong line or interpreting it in another unit.

Do not assume the target can infer the base from a description saying per hundred. A reader may understand it, but the required structured relationship still needs implementation and validation.

Review precision before conversion

An equivalent per-item rate can require more decimals than the creator’s two-decimal price field supports. Rounding it before multiplying a large quantity can materially change the charge. Treat that as a model limit rather than a harmless display preference.

Likewise, converting quantity into another basis can exceed the app’s four-decimal limit. Review both sides together. Solving price precision by creating an unsupported quantity does not preserve the transaction accurately.

If the required basis cannot be represented faithfully, prepare the final invoice in suitable software. Do not change actual supplied quantities solely to force a desired net amount or conceal the original precision in notes.

Build a representative test

Use fictional cases for an individual-item price, a price per defined group and a fractional measured quantity. Record the expected commercial calculation before generation. Inspect actual quantity codes, base quantities and net amounts in the target.

Include a missing or inconsistent base case under the target rules. Check that the implemented workflow reports the issue rather than silently assuming one where that changes meaning. Keep expected and actual results with the file and configuration.

Change the physical quantity in a second test and confirm the price basis remains appropriate. A single matching total can hide a hard-coded conversion that fails on the next invoice.

Complete the mapping responsibly

Keep unit definitions, source agreements and any conversion decision with the final record. Formal code-list and schema checks are necessary where required, but they cannot establish that a pack actually contains the quantity the preparer assumed.

The creator’s JSON, CSV and printable output remain application outputs. They do not provide formal UBL price-base support, code validation or recipient acceptance. A final exporter must genuinely implement those relationships and preserve the confirmed business facts.

A useful review explains the supplied quantity, unit, quoted base and resulting amount separately. It lets a colleague reproduce the charge without reading a private note or guessing what a familiar unit label was intended to mean.

For a fictional grouped-price case, record physical count, quoted base and expected amount separately before testing. Change the count in a second case while preserving the agreed rate basis. If the exporter continues to produce the original amount, investigate a hard-coded conversion or lost relationship. Do not approve the first matching example as general support. Include a source requiring unsupported precision and confirm that the workflow identifies the limitation rather than silently rounding the agreement into a different charge.