Built in Pakistan, for Pakistani tax — not localised afterwards.
Withholding tax is 5 fields on the sales invoice, NTN and CNIC are checked as you type them on the customer record, and Annexure C exports with all 13 statutory columns under your STRN. You still file it — Polaris does not talk to FBR yet.
Withholding tax is a field set, not a comment box
A customer who deducts tax at source hands you a certificate. In most software that certificate ends up typed into a notes box, where no report can reach it. On a Polaris sales invoice it is 5 first-class fields: whether withholding applies, the amount, the certificate number, the certificate date, and who deducted it.
Those fields roll into the WHT summary report, where net receivable is the invoice total minus the withholding. You chase what the customer still owes, not the gross figure they were never going to pay.
A customer NTN is checked as 1234567-8 — seven digits, the hyphen, one check digit — and a CNIC as 12345-1234567-1. Both are checked in the browser as the digits are typed, on the customer record itself, so a bad number is caught while the person who can correct it is still standing there.
FBR Annexure C, with all 13 columns filled
Not a spreadsheet you finish by hand. The export is built from the period's invoices and writes every statutory column the annexure asks for, in the order it asks for them.
- 01Serial number
- 02Sale type
- 03Buyer NTN
- 04Buyer CNIC
- 05Buyer name
- 06Document type
- 07Invoice number
- 08Invoice date
- 09Rate of tax
- 10Value excluding tax
- 11Sales tax
- 12Tax withheld
- 13State
Named for your STRN
The registration number is carried through from your store settings: the file is named for it and it is stated in the export summary.
Streamed in 1,000-row chunks
A full quarter is written out in chunks rather than assembled in memory, so a long period does not fall over halfway through.
Audited every time
Each export writes an audit line — who pulled the file, and when. The record of what left the system is part of the system.
Polaris produces the file. You file it.
There is no IRN, no FBR QR stamp and no IRIS connection in the product today. Nothing is transmitted to FBR on your behalf, and nothing on an invoice is certified by them. What you get is a correct Annexure C file and the reports behind it. You still file it — Polaris does not talk to FBR yet.
Direct FBR digital invoicing through PRAL is on the roadmap, not in the product. If you need certified digital invoicing end-to-end today, Polaris is not that yet — and we would rather you knew before you paid than after.
Net GST, with input tax claimed once
Output tax sums from bills that were not cancelled. Input tax is assembled from two places at once — supplier purchase orders and supplier ledger entries — because that is where it actually lives in a working shop.
Then it is deduplicated: any ledger document whose normalised invoice number already matches a purchase order for the same supplier is counted once, not twice. Net liability is output minus the combined input, and the whole thing can be grouped by month.
The rate itself is yours. Tax is configured once for the organisation, with a per-product override for the lines that differ. Onboarding asks for the rate — the standard one here is 18% — and treats it as exclusive; inclusive pricing is a switch in Tax Settings afterwards.
Polaris ships no default rate, and onboarding refuses a rate at or below zero once tax is switched on. The merchant is the one who knows which of their lines carry it.
Ramadan demand runs off the Hijri calendar
A seasonal demand event is Islamic, fixed or custom, and carries Gregorian dates like anything else — fixed is the default. Mark it Islamic and it also carries a Hijri month and day, so the pattern travels with the Islamic calendar instead of drifting eleven days a year from the season it describes.
That is how Ramadan is modelled. A pattern recorded against 1 Ramadan lands in the right week next year, and the year after, with nobody editing a date to keep it there.
Reports run on Karachi time
A scheduled report runs at the time you choose, in the timezone you name, against a server that keeps UTC. The 8am summary is 8am where the shop is, not where the server is.
Monthly schedules run on a day between 1 and 28, so a month-end report never skips February and never lands on a date that does not exist.
Denominated in rupees
PKR leads a 15-currency table rather than sitting somewhere down a dropdown. The figures a shopkeeper meets during a shift arrive as rupee amounts that mean something here — each one a setting you edit, where zero means no limit at all.
A shift closing further than this from the counted cash is flagged rather than waved through.
How much a single return can come to when the customer has lost the bill.
The daily total across the whole store, so the exception stays an exception.
WhatsApp is the front door
A number typed the way people type it here — 03xxxxxxxxx — is normalised to its international form before a link is built, so the share link opens the right chat the first time instead of failing quietly.
Support runs on the same channel, on every plan. Same-day reply on business days, on +92 335 070 6014.
Your records come off Excel and paper
That is what they are actually kept in — a spreadsheet and a hand-written register. The team enters your customer list, your supplier list and your stock with you, free.
There is no Tally importer and no QuickBooks importer. It is done manually, together, once.