Client project
Industry: Accounting & Tax Compliance
An E-Invoicing Extension That Never Signs Without Human Approval
- Chrome Manifest V3
- JavaScript
- Web Crypto API
- AES-256-GCM
- ECDSA P-256
- Cloudflare Workers
- Cloudflare D1
- ExcelJS
Delivery duration: Defined after discovery; no verified delivery record published.
Overview
Our own product: an independent browser extension for Egyptian accounting and finance teams that adds bulk export, reconciliation against the VAT return, an encrypted archive and e-invoice issuing on top of the Egyptian Tax Authority's e-invoicing portal. It has shipped, with a free trial, a paid licence and a live licensing service.
The Challenge
The portal shows invoices one page at a time, with no bulk export, no reconciliation against a VAT return and no archive, so accounting teams were copying data by hand. Fixing that meant running code inside a government website we do not control and that can change without notice, where our code shares the page with every other script loaded there, all while handling signing-certificate PINs, ERP secrets and live tax data.
The Solution
We drew a hard trust boundary through the extension. The code running inside the portal page can prepare and queue an invoice, but it can never sign or submit one. Certificate PINs and ERP secrets are held only by the extension's background service worker, in memory, and every signature waits for a person to approve it in a separate Secure Console window the page cannot reach. The extension's local database refuses to store any field named token, authorization, PIN, password or client secret, so a later code change cannot save one by accident, and if the selected company does not match the tax registration signed in to the portal, the extension stops instead of exporting another company's invoices. Archives sit in a password-locked, per-company AES-256-GCM vault and backups are encrypted with AES-256-GCM, with keys derived through PBKDF2 at 310,000 iterations. Paid licences carry an ECDSA P-256 signature, bound to the installation code and an expiry date, that the extension verifies without a network call. An update is accepted only if it matches a SHA-256 hash and carries a valid ECDSA P-256 signature, checked against a public key the user has pinned. The design has not had an external security assessment.
How we verify success
Before implementation, we agree on a baseline and acceptance criteria. Performance, security checks, recovery tests, and operational handover are documented against that baseline. No improvement figure is claimed here without a verified measurement.