Source: PINT-AE BIS Invoice v1.0.2 Schematron

Rule at a Glance

ID Severity Context (XPath)
BR-27 Fatal (error) ubl:Invoice/cac:InvoiceLine/cac:Price / cac:CreditNoteLine/cac:Price
Schematron ID: ibr-027  |  Field: IBT-146 (Item net price), cac:Price/cbc:PriceAmount

Classification

Transaction Data — BR-27 is a value constraint on the item net price validated by BR-26. Where BR-26 checks that the price field exists, BR-27 checks that the value it contains is greater than or equal to zero. The two rules work in sequence: BR-26 ensures presence, BR-27 ensures the sign is commercially meaningful.

What the Rule Is Checking

The test is straightforward: (cac:Price/cbc:PriceAmount) >= 0. Any numeric value of zero or above passes. A negative number — regardless of how small — fails with a fatal error. The rule does not distinguish between intentional negative pricing and a data error; the standard simply does not permit negative unit prices on invoice lines.

This distinction matters because some ERP systems handle certain scenarios by writing negative line prices. A common example: posting a price reduction as a negative unit price rather than a line-level allowance. Under PINT-AE, price reductions at line level belong in the cac:Price/cac:AllowanceCharge block as a discount against the gross price, producing a net price that is zero or positive. The negative-price shortcut that may work internally in the ERP will be rejected at transmission.

Why This Rule Exists

The PINT-AE standard defines the invoice line net price as the price of an item after discounts but before VAT. Economically, a unit price below zero implies the seller is paying the buyer per unit — a situation that does not correspond to a normal supply of goods or services. Where a seller is effectively paying a buyer (a rebate, for instance), the mechanism is a credit note, not a negative-price invoice line. This rule enforces that structural distinction at the point of validation, before incorrect data reaches Corner 5.

There is also a VAT arithmetic consequence. A negative unit price multiplied by a positive quantity produces a negative line net amount. That negative line net amount would reduce the document-level taxable base, potentially producing an incorrect — or negative — total VAT amount. The rule prevents that arithmetic cascade at its source.

UAE Data Example

PASSES ✓
<cac:Price>
  <cbc:PriceAmount currencyID="AED">250.00</cbc:PriceAmount>
</cac:Price>

<cac:Price>
  <cbc:PriceAmount currencyID="AED">0.00</cbc:PriceAmount>
  <!-- Zero is valid — e.g. a free-of-charge promotional item -->
</cac:Price>

FAILS ✗
<cac:Price>
  <cbc:PriceAmount currencyID="AED">-50.00</cbc:PriceAmount>
  <!-- Negative price — BR-27 fatal error -->
</cac:Price>

What Your ERP / IT Team Must Ensure

  • Add a pre-transmission validation check that rejects any invoice line where PriceAmount is negative. This check should run before XML generation, at the point where the ERP builds the line data, so the error surfaces in the user's workflow rather than at the ASP gateway.
  • Review how your ERP handles line-level price reductions. If the system writes a negative price to represent a discount, the PINT-AE output layer must convert that into a line allowance (cac:Price/cac:AllowanceCharge with a positive cbc:Amount) and express the net price as a non-negative value.
  • For credit notes, the mechanism for reversing a supply is a positive quantity on the credit note line combined with a positive unit price — not a negative price on the original invoice structure. Confirm your credit note generation follows this pattern.
  • Check whether any internal pricing workflows allow negative prices for promotional, bundle, or contra-item scenarios. Each such scenario needs a compliant PINT-AE treatment mapped before go-live.
  • BR-28 applies the same non-negative constraint to the gross price (IBT-148). Both rules should be addressed together in any ERP price-handling review.

Related Rules

BR-26 (item net price presence) · BR-28 (item gross price not negative) · BR-CO-10 (line arithmetic consistency)