Privacy Policy
Last updated: 28 August 2026
Navira is operated by SHAHMCO. This policy sets out what personal data the service handles, where it is stored, how long it is kept, and how to make a request about it. It describes the service as it is built today. Where something is planned but not yet in operation, it says so rather than implying otherwise.
1. Who we are, and which data we control
Navira handles two kinds of personal data, in two different roles, and the difference decides who you should talk to.
Data we control. Your account and company data — the name, email address and role of each person in your workspace, your company details, and the record of your relationship with us (billing, support, audit trail). We decide what is collected here and why, so requests about it come to us.
Data we process for you. Everything you enter about your own customers — their names, contact details, addresses and tax numbers — is processed on your instructions and on your behalf. We do not use it for our own purposes, do not sell it, and do not use it to train anything.
If you received an invoice from a business that uses Navira and you want to know what is held about you, contact that business first. It decides what to collect and how long to keep it, and it is the party that can act on your request. If it asks us for help in answering you, we will help. If you write to us directly, we will pass your request to the merchant and tell you that we have done so.
2. What we collect
Account data: your name, email address, password hash, role and interface language. Company data: company names, VAT/TRN and commercial registration numbers, national addresses, the bank account or IBAN shown on your invoices, and branding assets. Business records you enter: customers, products, invoices, credit and debit notes, expenses, uploaded receipts, bank statement lines and journal entries — including your customers' names, contact details, addresses and tax numbers. Technical data: standard server logs (IP address, timestamp, request path) kept for security and debugging, and a server-set timestamp of your last activity used to enforce the session timeout. Usage data: which pages you open in the app and a short list of actions you take in it — see section 11, which sets out exactly what is and is not collected.
No card data, ever. Subscriptions are invoiced and settled by bank transfer. There is no card payment rail in the product, so we never receive, process or store a card number, and no automatic charge against a stored payment method is possible.
3. How we use it
To operate the Service: generating compliant invoices and VAT returns, submitting e-invoices to ZATCA when you enable Phase 2, sending invoice emails and reminders you trigger, and providing support. We also use the usage data described in section 11, when it is enabled, to understand which parts of the product are working and which are not, and to detect and fix errors. We do not sell your data and do not use it for third-party advertising.
We ask for your consent where consent is required, and otherwise process only what is necessary to deliver the service you signed up for and to meet obligations the law places on us — chiefly tax record-keeping. Where you have given consent, you can withdraw it (see section 9), and withdrawing it does not affect processing that already happened.
4. Where your data is stored
Data is stored in a Supabase (PostgreSQL) database hosted on Amazon Web Services in the US East region (us-east-1, Northern Virginia, United States). Each company's records are isolated with database row-level security, so one workspace can never read another's data. Backups are managed by Supabase. The application is served by Vercel. Transactional email is processed by Resend in the Asia-Pacific region (Tokyo, Japan). Uploaded receipts and logos are held in Supabase file storage in the same US region as the database.
No production data is stored inside Saudi Arabia or the UAE today. An in-Kingdom archive location has been prepared in Jeddah, but it holds no data and nothing is written to it. If that changes, this section will be updated before the change is made, not after.
5. Transfers outside Saudi Arabia and the UAE
Because the infrastructure described in section 4 sits outside the Kingdom and outside the UAE, personal data you enter is transferred abroad and processed there. That is a real transfer, and we would rather state it than bury it.
The safeguards that apply to it: all traffic is encrypted in transit with TLS; data at rest is encrypted by the hosting provider on disk and in backups; tenants are isolated at the database level so a provider-side query still cannot cross a workspace boundary; administrative keys are held server-side and are never exposed to a browser; and each provider is engaged on contractual terms that limit it to processing on our instructions for the purpose it was engaged for.
A formal assessment of these transfers is in progress and is not complete. We will say so here until it is finished, and we will update this section when it is rather than quietly changing the wording.
6. Service providers we use
Each provider receives only what it needs to perform its function. This is the complete list for the service as it runs today.
| Provider | What it does | Where it processes | What it receives |
|---|---|---|---|
| Supabase | Database, authentication, file storage | us-east-1 (Northern Virginia, United States) | All workspace data: account and company data, your customer records, invoices and line items, uploaded receipts and logos. |
| Vercel | Application hosting and delivery | Global edge network; United States company | Request data in transit, plus standard server logs — IP address, timestamp, request method and path. Not a store of your business records. |
| Resend | Transactional email (invoices, reminders, account mail) | ap-northeast-1 (Tokyo, Japan) | The recipient address, the subject, the message body and any attachment you send — which for an invoice email includes the invoice PDF and therefore the buyer details printed on it. |
| ZATCA Fatoora | Government e-invoice clearance and reporting | Saudi Arabia | The invoice itself, including the buyer name, tax number and address where the document type requires them. ZATCA is a tax authority, not a supplier we chose: submission is required by law once you operate under Phase 2. |
| PostHog | Product usage analytics — not currently in use | United States | The narrow, filtered event data described in section 11. Never your business records. Switched off on 2026-09-03 and not receiving anything. |
| Sentry | Server error monitoring | United States | Error type, message, code location and scrubbed request path, as described in section 11. Enabled. |
There is no payment processor on this list because there is no card rail in the product (section 2), and no advertising or data-broker service on it because we sell software, not data.
7. How long we keep data
| Data | How long we keep it | Why |
|---|---|---|
| Account data (name, email, password hash, role) | For as long as the workspace is active; removed when the workspace is deleted | It is what gives you access, and what makes the audit trail meaningful — an action has to be attributable to somebody. |
| Company data (VAT/TRN, CRN, national address, IBAN, logo) | Life of the workspace; the parts of it printed on issued tax documents are retained with those documents for 6 years | It identifies the seller on every invoice, which makes it part of the tax record rather than a profile setting. |
| Your customer records (name, email, phone, address, tax number) | Life of the workspace, or until you delete the customer; a request to erase is handled as described in section 8 | You control this data — we hold it because you need it to raise invoices and chase payment. |
| Invoices, credit and debit notes and their line items, including the buyer name and address frozen on the document at the moment of issue | 6 years from the end of the tax period the document falls in | Saudi tax law requires invoice records to be kept for six years. An issued invoice also cannot be edited or deleted in Navira by design — corrections are made with a credit or debit note that references the original. |
| Uploaded receipts and expense attachments | With the record they are attached to; 6 years where they evidence an expense claimed for VAT | A receipt is the supporting document for an accounting entry, so it inherits its retention. |
| Server logs and the invoice audit trail | Server logs: the short operational window our hosting providers apply, used only for security and debugging. Audit trail: kept alongside the invoice for the same 6 years. | Security and fault diagnosis for the logs; for the audit trail, showing who issued or changed a document is part of what makes the record trustworthy. |
| Email delivery logs (recipient, message type, status, timestamp) | Life of the workspace | Evidence that an invoice or reminder was actually delivered, and the basis for the sending limits that stop the service being used to send bulk mail. |
Where a longer statutory period applies to a particular record, the longer period wins. You can export everything at any time (section 9).
Closing a workspace. An archived workspace enters a 30-day grace period before deletion. The automated job that would carry out that deletion is written but deliberately switched off, because a cron that hard-deletes tenant data is not something to leave running unattended. So nothing is hard-deleted automatically today; deletion is performed manually on request, and the retention rules above still apply to the tax records inside it.
8. Deletion requests, and the records the law requires us to keep
A request to delete personal data cannot remove an issued tax invoice. Saudi tax law requires the invoice record to be kept for six years, and Navira enforces the same thing in software: an issued document is immutable, and the correction mechanism is a credit or debit note, not an edit or a deletion. Any promise to erase an invoice on request would be a promise we could not keep and that you should not want us to keep, because the record protects the merchant as much as it constrains them.
What happens instead. A deletion request is met by anonymising rather than erasing. The identifying details in the customer record are removed: the name is replaced with a placeholder, and the email address, phone number and address are cleared. The invoice documents themselves are retained, including the buyer name and address frozen onto the document when it was issued, the tax number, and the city and country — that frozen snapshot is the tax context that makes the document a valid record, and stripping it would invalidate the record rather than protect the person.
The practical effect. You stop appearing as a contact in the merchant's customer list, no new invoice, reminder or correspondence can be addressed to you, and your details are no longer available for reuse. The historical documents remain a tax record until their retention period expires, after which they fall out of the exception above.
Status, stated plainly. The tooling that performs this anonymisation is built but is not yet released, and is gated behind review before it can run against live data. So a request today is carried out by hand, every request is reviewed before anything is changed, and we will tell you exactly what was anonymised, what was retained, and on what basis.
9. Your rights, and how to exercise them
You may ask us to:
Access — confirm whether we hold personal data about you and give you a copy of it. Correct — fix data that is inaccurate, out of date or incomplete. Destroy — delete your personal data, subject to the records the law requires us to keep, which are explained in section 8 rather than hidden behind a general exception. Port — receive your data in a structured, commonly used, machine-readable format. You do not have to wait for us to do this: Settings ▸ Export my data produces a download covering eleven sections of your workspace, and it keeps working after a plan lapses, because a business must be able to walk out with its own records. Object — object to a specific processing activity, including product analytics, and withdraw any consent you have previously given.
Where to send a request. privacy@shahmco.com. If you are in Saudi Arabia you may make a request under the Personal Data Protection Law; requests are handled the same way wherever you are. There is no charge. We may need to verify your identity before acting, so that we do not disclose or destroy somebody's data on the word of a stranger.
How quickly we respond. Within 30 days of receiving the request. If a request is complex or covers a large volume of records and will take longer, we will tell you within those same 30 days, say why, and give you a date.
If your invoice was issued by a business that uses Navira, see section 1 — that business is the one to ask first, and we will support it in answering you.
10. Cookies
| Cookie | What it does | Necessary? |
|---|---|---|
navira-lang | Remembers whether you read the site and the app in English or Arabic. | Strictly necessary — without it the page cannot render in your language. |
navira-country | Remembers which country version of the site you selected, so the tax rules, pricing and content shown are the right ones. | Strictly necessary for the site to show you the correct jurisdiction. |
sb-…-auth-token (set by Supabase Auth; split across numbered cookies when the token is large) | Keeps you signed in to your workspace. | Strictly necessary — this is the sign-in itself. |
navira_sa | A server-set, HTTP-only timestamp of your last activity. It is what enforces the 20-minute idle timeout and the 12-hour session cap. | Strictly necessary — it is a security control, not a preference. |
navira-plan-preference and navira-billing-preference | Carry the plan and the billing period you picked on the pricing page through to signup, so you do not have to choose twice. Set only if you arrive at signup from a link that names a plan, and they expire after 30 days. | Functional. They hold a choice you already made; they identify no one. |
navira_ref | Records the referral code in the link you arrived on, so whoever referred you is credited when you sign up. Set only if the link carries a ref code, and it expires after 30 days. It is a first-party cookie holding that code and nothing else — it does not follow you to other sites. | Not strictly necessary. It is attribution, not advertising. |
| Product analytics cookie and browser storage entry | Recognises a returning visit so one person is not counted as several. Set only if product analytics is enabled, and only with your consent. Not set today — analytics is not enabled. | Not necessary. Optional, and off unless you agree to it. |
We set no advertising cookies and no cross-site tracking cookies, and the tokenised customer portal sets none of the optional ones at all.
11. Product analytics & error monitoring
One of the two is in use. Error monitoring is on. Product analytics is off — it was switched off on 2026-09-03 and receives nothing at all; the analytics code is not even present in the pages your browser downloads, and there is consequently no cookie banner to answer. The limits described below stay on the record either way, so they are a commitment rather than a description of one moment's configuration.
Error monitoring runs on our servers only — there is no error-tracking code in your browser, so nothing is sent from your device. When server code fails, a scrubbed report is sent: an allowlist of structured fields plus pattern redaction over free text, so invoice contents, VAT and tax registration numbers, customer names and credential material do not leave the process.
The two services are PostHog (product analytics, not in use) and Sentry (error monitoring, in use). Both process data on servers in the United States. If product analytics is ever switched back on it will load only after you consent, and you will be able to withdraw that consent at any time.
What PostHog would receive. Which pages you open inside the app; a fixed, published list of product actions — signing up, creating a workspace, completing a setup step, issuing a document, a ZATCA submission being accepted or rejected, saving a VAT return, exporting a report, and reaching a plan limit; standard technical details your browser sends (browser, operating system, screen size, language, the page you arrived from); and two opaque identifiers — a random workspace ID and a random account ID — plus your plan, country, role and interface language. IP-based location lookup is switched off.
What PostHog would never receive. No invoice, quotation, credit note or line item. No amounts, totals or VAT figures. No customer names, contact details or tax numbers. No VAT/TRN registration numbers. No company names — yours or your customers'. No email addresses, no user names, no bank or IBAN details. Nothing from the ZATCA signing and clearance code, and no certificate, key or credential of any kind. Web-page session recording and automatic click capture are disabled, so no screen of yours is ever recorded. Every event passes through a filter that drops anything not on the published list before it leaves our servers or your browser.
Your customers are not tracked. The tokenised customer portal and payment pages are excluded entirely — no analytics code loads there, and no page view or event is recorded for a visitor who arrives through a link you sent them.
What Sentry receives. Error monitoring runs on our servers only; there is no error-tracking code in your browser. When server code fails, Sentry receives the error type, the message, the code location, and the request method and path with the query string removed. Request bodies, cookies, headers, and user identifiers are dropped before sending, and error text is scanned and redacted for tax numbers, IBANs, email addresses and phone numbers.
If analytics is enabled later and you would prefer your workspace to be excluded from it entirely, write to the address in section 14 and we will exclude it.
12. Security, and who can see your data
Passwords are hashed. All traffic is TLS-encrypted. Every table carries database-level row-level security, so one company's data is not merely hidden from another in the interface — the database refuses to return it. Authenticated pages are served with no-store cache headers. Sessions end after 20 minutes of inactivity and after 12 hours regardless, enforced on the server rather than in the browser.
What is encrypted, stated precisely. ZATCA signing credentials and payment-gateway secrets are encrypted at the column level with AES-256-GCM under a key held outside the database, so a copy of the database alone cannot sign an invoice in your name. Personal data is not separately encrypted column by column: it is protected by the tenant isolation described above and by the encryption our hosting provider applies to disks and backups. We spell this out because the distinction matters when you assess us, and a vaguer sentence would read better while telling you less.
Operator access. Support staff do not browse workspaces freely. Where an operator needs to see what you see in order to resolve a problem, the mechanism is constrained by design: a read-only database role, a short-lived token, revocation on the server at any time, and a log entry for every session that records who acted and the stated reason for acting.
Report vulnerabilities to the address in section 14.
13. If there is a breach
If a breach affecting personal data occurs, we notify the competent authority within 72 hours of becoming aware of it, and we inform affected users without undue delay — what happened, which data was involved, and what we are doing about it. Where the data affected belongs to a merchant's own customers, we notify the merchant so that it can meet its own obligations towards those individuals, and we give it the detail it needs to do so.
14. Contact
Privacy questions, data subject requests and vulnerability reports: privacy@shahmco.com. See also our Terms of Service.