Bardibas RetailOS

Nepal's Inland Revenue Department requires VAT-registered retailers to transmit every invoice in real time to the Central Billing Monitoring System. Most small retailers run unlicensed desktop software that cannot do this, which leaves them exposed at audit. Imported SaaS does not handle the Bikram Sambat calendar, Nepali fiscal years, or Schedule-8 VAT.

Build a system that is simultaneously a point-of-sale, a double-entry ledger and a regulated fiscal device — where an invoice is not considered issued until the tax authority acknowledges it, and where the law dictates which country the database may physically sit in.

• 01Started on Firestore (19 Dec 2025) for speed to a working POS — and hit its limits within two weeks. A tax-compliant system needs atomic multi-table transactions, a relational double-entry ledger and per-tenant isolation; a document store gives you none of the three.
• 02Moved the system of record to PostgreSQL. First Supabase commits landed 30 Dec 2025; the Firestore data layer was removed on 15 Jan 2026 — roughly four weeks to change the data paradigm while continuing to ship features.
• 03Then the regulation ruled out managed hosting entirely. Nepal's Electronic Billing Directive 2074 (amended 2076/09/09) requires the central server to be located inside Nepal with IRD access. So I self-hosted the whole Supabase stack — Postgres, Edge Runtime, auth, storage — on a Nepal VPS, and cut production over on 14 Apr 2026.
• 04Took on running it: migrations, backups, WAL archiving, uptime monitoring on a 10-minute cycle, and incident response. One production incident traced to an rclone WAL-archiving cron with no flock, accumulating processes until OOM; resolved and the analytics table reclaimed 38GB.
• 05Designed a multi-tenant schema with row-level security isolating every tenant's ledger, inventory and fiscal records.
• 06Built Nepal-specific compliance as first-class domain logic: Bikram Sambat calendar, fiscal-year-scoped invoice numbering, PAN/VAT modes, HS codes, Schedule-8 VAT and Annex 5 XML export — then real-time CBMS transmission with per-invoice acknowledgement persistence.
• 07Commissioned a chartered-accountant-level database audit against my own system — 38 findings — and worked them as a backlog rather than filing them away.
• 08Shipped Pasal, a per-tenant storefront on a subdomain, as a paid add-on to the core platform.

I commissioned an independent database audit against my own live system; it raised 38 findings — the honest cost of moving a financial data model from a document store to Postgres under a regulatory deadline. The core money layer runs on fixed-point decimal with ROUND_HALF_UP throughout, VAT computation included. The migration still in progress sits at the presentation layer, where aggregation call sites total with floating point; those are being replaced one at a time, alongside closing row-level security placeholders left during the migration and verifying CBMS acknowledgement retry. Money-handling code earns trust by being audited, not by being called robust.