Petrol pump software, built in Pakistan, for how Pakistani stations actually run.

As of the OGRA notification effective 16 May 2026, petrol (PMG) is Rs 409.78 per litre and high-speed diesel (HSD) is Rs 409.58 per litre across Pakistan. OGRA revises fuel prices roughly twice a month, around the 1st and the 16th, with occasional off-cycle changes. In Sitara Infotech's petrol pump software you update the price once with an effective date, and every sale after it automatically uses the new rate while the old price stays in history.

You enter the new price once with the date it takes effect. From that moment every sale reprices automatically, the previous rate is kept on record for reporting and audit, and you never re-key prices at each nozzle. This is the first thing the walkthrough demonstrates, and it mirrors the OGRA fortnightly revision cycle that Pakistani stations live with.

Yes. Credit (udhaar khata) is a core module: credit limits, multi-vehicle fleet accounts, receipts that allocate against the oldest balance first, ageing, and statements that reconcile. The paper register becomes a ledger that ties out at month-end.

Yes. Sales tax invoicing, withholding, and audit-ready ledgers, with PRA or FBR e-invoice posting where a station requires it. The chart of accounts is editable and your accountant works in the format they already know.

Both, in one system. Automated dispensers poll their readings into the POS in about ten seconds. For manual pumps, the attendant photographs the meter and OCR captures the litre value. Reconciliation runs against captured litres either way, not against operator memory.

Yes, with both QuickBooks Online and QuickBooks Desktop. A custom sync maps each sale, shift close, expense, and credit settlement to your own chart of accounts in real time, so the books are current rather than a month behind the pump.

An FBR POS usually drops because the integration retries the wrong way: it posts each invoice live to the FBR endpoint and, when the endpoint times out or the token expires, the till freezes or silently stops syncing. The fix is a queue-and-retry design that records every sale locally first, then reconciles with FBR in the background, so the counter never stops and no invoice is lost.

Mismatches happen when the local invoice counter and the FBR-returned invoice number drift apart after a failed sync. The correct handling is to treat the FBR number as the authority, store both, and reconcile on a schedule so duplicates and gaps are caught the same day instead of surfacing in an audit months later.

Yes. The till should keep selling on a local database during an outage and sync to FBR and the cloud once the connection returns. For forecourts on weak DSL or load-shedding, offline-first is the difference between trading and shutting the pump. Every sale is timestamped locally so nothing is lost in the gap.

We connect at the layer where each sale is already recorded. On a forecourt with a pump controller or vendor software, the software reads every dispense, fuel type, volume, rate, and nozzle in real time from that system. On a station without one, an on-site edge box reads the pump meters directly. Either way the live sale flows into billing, FBR, stock, and credit with no double entry.

Both modes are supported. On an integrated forecourt the dispense is captured automatically the moment the nozzle finishes, so there is no keying and no room for a wrong figure. Where direct integration is not available, the attendant enters the meter reading and the system still runs billing, FBR, stock, and credit. Many stations start manual and move to automatic capture once the controller link is in place.

The integration is built around how the dispenser exposes its data, not its badge, so it is not tied to one make. Brands common in Pakistan include Gilbarco, Wayne, Tatsuno, Tokheim, and the widely used Censtar, Seraphim, and Sanki dispensers. For any site we first check how the pump or its controller reports each sale, then connect to that. If a pump cannot be read directly, the manual-entry mode still covers it.

If your station already has a forecourt controller, we integrate through it and read every nozzle from one point, which is the cleanest setup. If you do not have one, we either connect to the vendor software that records sales or place an on-site edge box that reads the pumps. A controller helps but is not a hard requirement, and we work with what the station already runs.

We do not supply the gauge, we build the intelligence layer on top of it. If a tank gauge is fitted, the software reads whatever it captures, tank height, volume, and temperature, then reconciles it against actual metered sales so the daily variance per tank becomes visible. That is how shortages, evaporation, and delivery gaps surface the same day instead of at the annual stock count. Where no gauge exists, manual dip readings feed the same reconciliation.

Yes. It tracks per-nozzle and per-tank dispensed volume, opening and closing dip readings, shift handover, and the variance between meter sales and tank stock so shortages show up per shift instead of at month end. Multi-pump and multi-station owners see each site and each shift separately in one dashboard.

The software sits on top of the payment methods the station already uses and ties each one back to the matching dispense, so card, cash, credit, and wallet sales reconcile in a single ledger. That covers bank card terminals, fuel-card switches, and wallets such as JazzCash, Easypaisa, and Raast. Where a bank, acquirer, or switch like 1LINK exposes an API, we integrate to it directly so settlement and sales match automatically rather than by hand.

We start every station by checking how its pumps, controller, and payment setup record data, then build the integration to that. If something cannot be read directly, the manual-entry mode keeps the station fully running on billing, FBR, stock, and credit from day one, while we work on the automatic link in the background. No station is turned away for having older or mixed hardware.