FBR Sales_Invoice_Template (.xlsm) Import: Bring Your Spreadsheet, Skip the Re-Keying

Most Pakistani businesses already keep their sales data in the FBR-issued Sales_Invoice_Template (.xlsm) workbook—the same spreadsheet some teams previously uploaded directly to the IRIS portal. Re-typing those rows into another invoicing tool just to satisfy FBR digital invoicing in Pakistan is wasted effort and a fresh source of typos. Wise Digital Invoice now imports that template as-is: drop the file in, customers and products are reconciled or created automatically, and lines that belong to the same invoice are grouped for you.

Auto-detection: no flag to flip

The importer accepts both our own simple template and the official FBR workbook on the same upload page. It detects the FBR layout by looking for a worksheet titled SALES_INVOICES (or the DOMESTIC SALES INVOICES banner in row 1) and switches readers automatically—header rows 1–6 are skipped and the data scan begins at row 7. If your file does not match, the standard template rules apply instead. You never have to tell the system which format you uploaded.

Column mapping in plain English

The FBR template uses a fixed column layout. The importer reads only the cells it needs and leaves everything else (formulas, named ranges, hidden lookup sheets) alone:

• B — Buyer NTN/CNIC. Used to match an existing customer, or to create a new one. Must be 7 or 13 digits after stripping formatting.
• C, D, E — Buyer name, registration type and province. Required only when the NTN/CNIC is new to your account.
• G — Document type (Sale Invoice or Debit Note). Empty cells default to Sale Invoice.
• H — Your own document number. For Sale Invoices it lands in Manual Invoice Reference; for Debit Notes it becomes the mandatory FBR reference invoice number. It also acts as the grouping key for multi-line invoices.
• I — Invoice date. Excel serial numbers, formatted strings and real dates are all accepted.
• J — HS Code. Trailing :- punctuation is stripped automatically.
• K, L — Sale-type description and tax rate. The rate is normalised whether you typed 18%, 18, 0.18 or Exempt.
• N, O, P — Quantity, UoM, and value of sales excluding sales tax. Unit price is derived as P ÷ N.
• Q, R, S, T, V — Sales tax amount, fixed/notified value, extra tax, further tax and ST withheld at source.
• W, X — SRO schedule number and item serial.
• AD — Validation status. The row is only imported when this column reads Valid, mirroring FBR’s own template gate.

Customers and products are reconciled, not duplicated

Two of the biggest spreadsheet headaches—mistyped buyer names and duplicate product rows—are addressed in the lookup phase before any record is created:

• Customers are matched by NTN/CNIC. If the buyer already exists in your account, the row is linked to that customer record exactly as the rest of the app would; name, province and type from the spreadsheet are not used to overwrite the existing profile.
• Products are matched by HS Code + UoM. A new product is only created when that pair does not exist in your catalog. Its price is set from the spreadsheet’s unit price and its sale-type id is inferred from the description in column K, falling back to Goods at standard rate when nothing matches.
• Unregistered, Unregistered Distributor and Retail Consumer all collapse to unregistered for the customer record, which keeps the downstream tax engine honest.

Multiple lines, one invoice

The FBR template puts each invoice line on its own row, even when ten rows really represent one ten-line invoice. The importer groups rows that share the same buyer NTN, invoice type, invoice date and document number (column H) into a single invoice with multiple line items. You get one invoice record per real-world sale, not ten almost-identical drafts to clean up.

Validate first, write second

The import runs in four phases—read, validate, group, persist—so the database stays clean when something is off. Every row is validated up front: NTN length, province existence, AD = Valid, mandatory HS code and UoM, non-negative monetary fields, and the same withheld-tax-vs-calculated-tax rule we enforce throughout the product. If any row fails, nothing is written; you see the row-numbered error list and fix the spreadsheet rather than rolling back partial inserts.

Plan quota is checked after grouping, so the importer can tell you the truth: “your plan allows N more invoices, this file would create M”—before a single record is created. If you are evaluating on a free trial, this is where the trial’s invoice limit shows up explicitly.

After the import: nothing is auto-submitted

Every imported invoice is created as a draft. They are not pushed to FBR automatically. You open each one, run the same Validate-then-Submit flow as a manually keyed invoice, and watch the FBR response land on the invoice detail page. That preserves the human checkpoint between “my spreadsheet” and “the FBR’s record”, which is exactly where most invoice errors get caught before they become rework.

When the standard template is still the right choice

The simpler in-app template (a clean .xlsx available from the same import page) is still ideal when you are entering a handful of invoices a week against an already-clean customer and product master. The FBR template shines when:

• Your accounts team already prepares that workbook for other regulatory reasons.
• You have months of historical sales to onboard from one consolidated file.
• Customers and products are still being normalised and you want them auto-created from the data rather than maintained twice.

Either way, the import sits next to the same FBR API integration and printing pipeline as a manually keyed invoice—the imported records use the same calculation service, the same validation rules and the same print templates as the rest of your account.

Exact column letters and required fields reflect FBR’s current Sales_Invoice_Template layout (sheet SALES_INVOICES, data starting at row 7, validation gate in column AD). If FBR revises the template, the importer is updated to match; behaviour described here aligns with the import flow shipped in Wise Digital Invoice today.