Odoo offline mode is a Point of Sale capability. If the connection drops mid-trade, Odoo POS keeps scanning, pricing and taking payment, then syncs the day’s orders once the link returns. The rest of Odoo — Accounting, Inventory, Purchase — needs a live connection and has no offline equivalent.
For a retailer in Pakistan, that solves half the problem. A receipt is not a legal receipt without a tax invoice number from FBR, PRA, SRB or KPRA, and in a standard setup that number depends on the internet. No internet, no number. No number, no receipt you can legally hand a customer — even though the sale itself went through perfectly.
Trionex closes that gap. On a Trionex implementation, Odoo POS keeps selling and keeps printing receipts carrying a valid, authority-issued tax number through an internet outage, through an FBR or provincial gateway outage, and through an Odoo server outage. Reporting to the authority catches up on its own once connectivity returns — with no manual repair, no sequence to fix, and nothing provisional on the customer’s copy.
Trionex is the first implementation partner in Pakistan to keep tax-number punching alive while Odoo POS is in offline mode.
“We were offline” means four different things
When a store manager reports an outage, they could mean any of four situations. They fail differently, and a setup that handles one does not necessarily handle the others.
| What actually happened | How common | Standard Odoo POS | Trionex implementation |
|---|---|---|---|
| Internet down, store still powered and running | Weekly in many areas | Keeps selling, cannot print a legal receipt | Keeps selling and prints with a valid tax number |
| Odoo server down or unreachable | Occasional | Keeps selling, orders wait | Keeps selling, printing and fiscalising; everything catches up |
| FBR or provincial gateway slow or down, your internet fine | The most frequent of the four | Billing stalls on every single invoice | Unaffected — customers never notice |
| A single till drops off the store network | Occasional | That terminal cannot issue a tax number | That terminal keeps trading |
Why the distinction matters commercially
Most Pakistani retailers buy “offline POS” expecting it to cover all four rows. Standard Odoo covers the selling side of two of them, and none of them for the tax number. The row that catches people out is the third: your internet is fine, your Odoo is fine, and billing still stalls because the authority’s gateway is having a bad afternoon. Offline mode does nothing there, because the POS is not offline at all. It is online and waiting.
The one-line version
Odoo offline mode keeps the sale alive. On its own it does nothing for the tax number. Those are two separate dependencies, and in Pakistan you need both before you can hand a customer a receipt.
What Odoo POS offline mode gives you out of the box
Odoo POS is designed so that a cashier is not waiting on the server for every scan. Once a session is open, routine selling continues even if the connection goes. That is genuinely useful, and it is worth being precise about where it stops.
| Keeps working during an outage | Stops, or quietly goes wrong |
|---|---|
| Scanning, pricing, discounts and tax calculation | The tax invoice number on the receipt — the one that stops the till |
| Taking cash and completing the sale | Live stock figures, which go stale as the outage runs on |
| Opening the cash drawer | Loyalty balances and gift card validation |
| Printing a non-fiscal slip | Refunds against a receipt from an earlier session |
| Splitting bills and refunds within the session | Adding new products |
| Restaurant floors, tables and running orders | Closing the session, until everything has caught up |
| Cash and standalone card terminals | Card payments through an integrated terminal |
The two that cause real arguments
Stock. An offline till will happily sell what you no longer have. For fast-moving retail that is usually tolerable; for serialised or scarce stock it is not. The decision belongs before go-live, not during an outage.
Loyalty and gift cards. These are authoritative on the server by design. How you handle them offline is a commercial risk decision, not a setting. The usual answer is to let customers earn offline and redeem only when you are back online.
The gap that actually stops the till
Here is the situation that sends a store manager looking for a new ERP partner.
The internet drops. Odoo POS switches to offline mode exactly as designed. The cashier scans, totals, takes the cash without a hitch. Then they hit Print — and nothing valid comes out, because the receipt has to carry a tax invoice number from FBR, PRA, SRB or KPRA, and that number depends on a service the till can no longer reach.
The POS works. The sale is complete. The receipt is not legal.
What the shop does next, and why both options are bad
Option one: stop billing. The queue backs up, customers walk, and the loss is immediate and visible. On an Eid weekend it is a serious number.
Option two: print a plain slip. Staff print an “estimate” or a cash memo to keep the line moving, fully intending to fiscalise it later. In practice later never comes cleanly, the invoice sequence ends up with gaps, and this is one of the most common ways a compliant retailer quietly becomes a non-compliant one. That is an enforcement finding, not a clerical slip.
What an outage actually costs you
- Lost revenue for every minute the queue is stopped — and outages have an unhelpful habit of landing at peak trading hours.
- Compliance exposure from every non-fiscal slip printed to keep customers moving, plus the sequence repair work that follows.
- Staff hours spent reconstructing the outage afterwards, usually at closing, usually by the one person who understands the system.
- A blind spot at head office: in most setups, nobody at HQ knows a branch stopped billing until the end-of-day numbers look wrong.
- Customer confidence, which is the one you never get a number for.
Now multiply by the number of branches, and by the number of bad connectivity days in a Pakistani trading year.
What changes when Trionex implements your Odoo POS
We will not publish our method — but the outcomes are easy to state plainly, and easy to hold us to.
| At the counter | Without Trionex | With Trionex |
|---|---|---|
| Internet goes down at 7pm | Sales continue, receipts cannot be printed legally | Sales continue and receipts print with a valid tax number |
| FBR or provincial gateway is slow | Every invoice stalls, queue builds | Customers never notice |
| Number on the printed receipt | Placeholder, or nothing at all | A real, authority-issued number at the moment of sale |
| After the outage | Manual fiscalisation, sequence repair, late nights | Reporting catches up automatically, with duplicate protection |
| Visibility during the outage | Discovered at closing time | Visible at head office from the first minute |
| If an auditor asks about those three hours | Reconstructed from memory and spreadsheets | A reconciliation report for the exact outage window |
The benefits in plain terms
- You never stop trading because of connectivity. Selling, tax numbering and printing all keep working through the outages that currently close your tills.
- Every receipt stays legal. Your staff are never put in the position of choosing between turning customers away and printing something they should not.
- Nothing is provisional. The number on the customer’s receipt is the real one. There is no reissue, no correction run, no sequence to repair the next morning.
- Compliance looks after itself. Reporting to the authority resumes and completes on its own, with protection against anything being submitted twice.
- You can prove it afterwards. A reconciliation report shows every sale, every tax number and every acknowledgement for the outage window — the document you hand an auditor instead of an explanation.
- One database across provinces. A group trading under FBR, PRA, SRB and KPRA runs a single Odoo setup rather than a separate integration per authority.
- Hosting stays your choice. Odoo Online, Odoo.sh or on-premise — the behaviour at the till does not change.
- Your Odoo stays upgradeable. We keep the compliance capability deliberately separate from the core, so upgrades remain routine rather than a project.
- It is proven before you depend on it. We induce a real outage during rehearsal and trade through it with you watching.
What your team actually experiences
The cashier sees an offline indicator and nothing else different. Same screen, same flow, same receipt. The entire training requirement is one sentence: if you see the offline badge, keep selling and tell the manager.
The manager sees which terminal is offline, how much is waiting to catch up, and how long the oldest pending invoice has been waiting. That last figure is the only one that matters for compliance, and it is visible from the first minute of the outage rather than discovered at closing.
Finance and compliance get a daily reconciliation they can sign off, and an evidence trail for any window in which connectivity was lost.
Not all “offline” claims are the same — what to check
Some integrations describe themselves as offline-capable because they print a provisional slip with a placeholder and issue the real tax number later. That is a different product. The customer walks out with a document carrying no authority-issued number, and somebody has to repair the sequence afterwards.
On a Trionex implementation, the number printed at the moment of sale is the real one. Ask any vendor which of those two things they are actually selling you, and ask them to demonstrate it with the internet unplugged.
What you get from Trionex as a partner
Keeping a store trading through an outage is not a single discipline. It needs the ERP, the software around it, and the physical store network to be designed together — which is why most projects fall between vendors.
| Capability | What it means for you |
|---|---|
| Odoo implementation | Certified Odoo expertise across POS, retail and restaurant operations, configured for Pakistani compliance from day one — and built so your upgrades stay straightforward. |
| Custom software development | Capability that does not exist in standard Odoo, built and maintained by us, so you are not waiting on a third party when something needs to change. |
| Network and infrastructure | Store networks, power protection and on-site remediation — the unglamorous work that decides whether a branch survives an outage at all. |
An Odoo-only partner cannot deliver the middle row. A general software house cannot safely deliver the top row. Neither delivers the bottom row without people who will walk into a store and re-cable it. That is what we mean by a 360° technology partner — one accountable party across the ERP, the software and the infrastructure, with no gap for a problem to fall into and nobody to point at when something breaks.
And beyond the build
- A rehearsed outage before go-live, not a promise that it would probably work.
- A written runbook so your staff are not improvising during an incident.
- Monitoring and alerting that escalates on compliance risk, not just on “something is down”.
- Honest limits, stated upfront — including the things no architecture can solve, which you will find in the next section rather than in month three.
Who this is for
- Multi-branch retail chains where a stopped till at one branch is invisible at head office until closing.
- Restaurant groups under PRA, SRB or KPRA monitoring, where dinner service is both the busiest hour and the least forgiving one for an outage.
- Tier-1 retailers, pharmacy and grocery chains with high transaction volumes and low tolerance for queue time.
- Any operator whose tills stop when the internet or the authority has a bad day.
- Any operator whose staff have ever printed a non-fiscal slip to keep a queue moving.
The honest limits
Any vendor who tells you offline mode has no limits is selling something. Here is the real list, and what we do about each.
Stock goes stale. An offline till sells from the figures it had when the session opened. There is no way around that. What we do: agree the policy by product category before go-live — which lines may oversell, which must block — and size the risk against your actual stock turn.
Loyalty, gift cards and integrated card terminals. All three depend on something outside the store. What we do: usually accrue loyalty offline and redeem online only, and keep a standalone card terminal as the fallback.
Extended outages still have a reporting deadline. Printing through an outage is not a licence never to report. Every regime has a window, and a multi-day outage can approach it. What we do: alerting escalates on the age of the oldest unreported invoice, not just the volume waiting, so the clock is visible long before it runs out.
A till that loses the store network is still a till that stopped. This protects you against the store losing the internet, not against a terminal losing the store. What we do: wired connections wherever physically possible, and each terminal kept independent so one failure never cascades.
Refunds against older receipts. A refund against a previous session needs the server. What we do: define the manual process in the runbook before go-live.
The Odoo backend does not run offline at all. Accounting, Inventory, Purchase and the rest need a connection, and always have. For most retailers that is acceptable — head office can wait an hour, a checkout queue cannot. It stops being acceptable when goods receipts or inter-branch transfers happen during trading hours. What we do: advise on hosting placement so that the operations you cannot pause stay available where they are needed.
Questions to ask any Odoo partner before you sign
Whether or not you work with us, these are the questions that separate a real answer from a confident one.
- Unplug the internet in a demo. Does a compliant receipt still print, with a real tax number on it?
- If the FBR or provincial gateway is down but our internet is fine, does billing continue?
- Is the number on the customer’s receipt final, or is it reissued later?
- After an outage, what do we have to do manually? Be specific.
- What can you show an auditor about an outage window six months from now?
- How do we know, at head office, that a branch has stopped billing — before closing?
- What happens to this when we upgrade Odoo?
- Will you rehearse a real outage with us before go-live?
- Who do we call at 9pm on a Saturday — and are they responsible for the ERP, the software and the network, or only one of them?
Frequently asked questions
Does Odoo work offline?
Odoo POS does. It holds what the cashier needs for the session, keeps selling if the connection drops, and syncs the orders once it returns. The Odoo backend — Accounting, Inventory, Purchase — needs a live connection and has no offline equivalent.
Can Odoo POS print an FBR or PRA invoice number offline?
Not in a standard implementation. The usual setup asks the authority for the number at the moment of printing, so no internet means no number and no legal receipt. On a Trionex implementation, the receipt prints with a valid tax number throughout the outage.
Is an offline-issued tax number real, or a placeholder?
Real, and issued against your registered POS identity. Nothing on the customer’s receipt is provisional, and nothing has to be repaired or reissued afterwards.
Will I lose sales if the internet goes down?
Not on a Trionex implementation. Selling, tax numbering and printing all continue. The only thing waiting on the internet is reporting to the authority, and no customer is standing at the counter waiting for that.
What happens to the data while the store is offline?
It is held safely and drains automatically once connectivity returns, with duplicate protection so nothing is posted twice. A reconciliation report covers the outage window, so you can show an auditor exactly what happened and when each invoice reached the authority.
Does this work for PRA, SRB and KPRA as well as FBR?
Yes. A group trading in Punjab, Sindh and Khyber Pakhtunkhwa runs one Odoo database and one compliance setup, rather than a separate integration per province.
How long can a store stay offline?
Selling and printing are unaffected for the duration of the outage. The practical limit is the authority’s reporting window, and alerting escalates on the age of the oldest unreported invoice, so you see that clock long before it runs out.
Does it work with Odoo Online, Odoo.sh or on-premise?
All three. Hosting choice does not change what happens at the till, which is what makes offline tax numbering possible even on a cloud deployment.
Will this complicate our Odoo upgrades?
No. The compliance capability is deliberately kept outside the core of Odoo, so your Odoo-side footprint stays small and version upgrades stay routine.
Can I still sell stock I do not have while offline?
Yes — that is inherent to any offline POS, because quantities go stale during an outage. Whether that is acceptable is a business decision we help you make by product category before go-live, not something to discover during an incident.
How do we know it works before we rely on it?
We prove it. Before go-live we deliberately induce an outage and trade through it, simulate an authority gateway failure, reboot a terminal mid-transaction, and review the reconciliation report with you. If your store has never traded through a rehearsed outage, nobody knows whether it can.
What does getting started involve?
A short offline readiness assessment covering your current integration, your measured performance at peak, your store networks and your reporting backlog. You receive a findings report whether or not you proceed.
Start with an offline readiness assessment
If your tills stop when the internet or FBR has a bad day, or your staff have ever printed a non-fiscal slip to keep a queue moving, there is a conversation worth having.
We begin with a short assessment of your current integration, your measured performance at peak, your store networks and your reporting backlog. You receive a findings report whether or not you proceed — and if the answer is that your current setup is fine, we will tell you that.
Tagged with :
