Why we built OmniBooks
Pakistani businesses were choosing between international accounting software that does not understand provincial sales tax, and local software that does not understand double entry. The first makes you maintain tax by hand. The second makes you maintain the books by hand.
We built one system that does both properly: a ledger strict enough to pass an audit, and tax handling that knows there are five revenue authorities, not one.
Four decisions that shaped the product
These are the trade-offs we made deliberately, and the reasons we would make them again.
One ledger, not four systems
Rules belong in the database
Pakistan first, not Pakistan later
Modular by construction
What OmniBooks actually is
Four sellable products — Books, HR, CRM and POS — sitting on one shared platform core: identity and access control, entitlements, approvals, audit, documents, notifications and a marketplace. Every module can be licensed, metered and switched on independently per company.
Underneath it is a multi-tenant system with row-level security enforced by the database, an append-only audit log with chain verification, and a domain event bus that connects modules — bills and invoices to inventory, POS sales to loyalty and the kitchen display, recruitment to HR.
The interface runs in English, Urdu and Roman Urdu.
At a glance
- Products
- Books, HR & Payroll, CRM, Point of Sale
- Jurisdiction
- Pakistan statutory — FBR, provincial authorities, EOBI, PF
- Languages
- English, Urdu, Roman Urdu
- Currencies
- PKR, USD, EUR regional pricing
- Access control
- ~300 permission codes across 22 domains
- Data isolation
- Postgres row-level security, non-superuser role