Invoice data
FBR Digital Invoice Required Fields: A Business Data Checklist
Understand the seller, buyer, invoice and item information that should be governed before digital invoice validation and submission.
Digital invoice quality depends on the quality of the underlying business record. The safest approach is to group data into four areas—seller, buyer, invoice header and line items—then assign an owner and validation rule to every field.
Seller information
Maintain the seller NTN or CNIC value used for the relevant registration, legal business name, province and business address. Do not let users freely retype these values on every invoice. Controlled company settings reduce spelling differences and accidental use of another branch or registration.
Buyer information
Buyer data commonly includes identification, business name, province, address and registration type. The information required can depend on the buyer and transaction. Keep evidence supporting the status used at the time of supply, and avoid guessing a registration type merely to pass validation.
Invoice header
Control invoice type, invoice date, seller invoice reference, related invoice reference where applicable, and the scenario used during sandbox testing. Your internal invoice reference should be unique and permanent so finance teams can trace an external result back to the original sale.
The official API examples distinguish sandbox data from production data. Scenario identifiers are used for sandbox testing, while production submissions follow the current production object model. Do not copy sample values into live invoices.
Line-item information
Each line may require an HS code, product description, rate, unit of measurement, quantity, values excluding sales tax, applicable sales tax and other conditional tax or SRO fields. Sale type, HS code, UOM and rate must make sense together; validation is not simply a check that every box contains text.
Use the official reference methods where applicable instead of maintaining uncontrolled lists. The public technical specification documents reference services for provinces, item descriptions, UOM, rates, HS/UOM relationships, SRO schedules and registration status.
Build field-level controls
For each field, document:
- its source system;
- the person responsible for accuracy;
- whether it is mandatory, optional or conditional;
- its accepted format;
- the rule that connects it with other fields; and
- what the team should do when validation fails.
Prevent blank required fields, invalid date formats, negative values where they are not expected and uncontrolled decimal rounding. Show line-level errors beside the relevant item so users do not have to decode a generic message.
Review totals and meaning
An invoice can be technically complete yet commercially wrong. Reconcile quantity × price, discounts, values excluding tax, tax amounts and invoice totals with the approved sale. Confirm that the product description is meaningful and that the selected tax treatment is supported by the actual transaction.
Source and disclaimer
Field examples in this checklist are based on the public Technical Specification for DI API, version 1.12, reviewed 10 October 2026. Technical models and tax requirements can change. Confirm the current specification and professional advice before production use.