TechnoMinds Fatoorah features
Everything below maps to implemented components with local test evidence in the underlying platform. External access and production proof remain separate gates. See our Security page for the same plain-statement approach applied to data protection, including what does not exist yet.
Invoice generation
Standard, simplified, credit & debit note support
One canonical invoice model covers standard tax invoices (B2B), simplified tax invoices (B2C), and credit/debit notes, with automatic classification of which submission path an invoice type requires.
Deterministic tax calculation
Tax is calculated with integer arithmetic, never floating point, so line items and totals always reconcile to the halala.
UBL 2.1-shaped invoice XML
Every invoice generates a UBL-shaped XML document, plus a human-readable rendering for internal review.
Immutable once issued
An issued, reported, or cleared invoice is never edited in place. Corrections are always a new credit or debit note referencing the original.
Cryptography & QR
Real key material, not a simulator
A genuine secp256k1 keystore, CSR generation, invoice-hash chaining, and digital signing back every invoice's security artifact.
QR TLV build, decode, and verify
Every invoice gets a scannable QR code built from the TLV elements ZATCA's e-invoicing model requires, with the same logic able to decode and verify a QR it produced.
Device lifecycle & onboarding
13-state EGS unit lifecycle
Every invoicing device/branch (EGS unit) moves through a defined lifecycle from setup through compliance onboarding to production, with renewal, suspension, and revocation states modeled explicitly.
Fail-closed production guard
A unit cannot be marked production-ready until its production credentials are actually validated — this is enforced unconditionally in code, not left to a manual checklist.
Customer action & OTP workflow
The taxpayer-facing steps required during onboarding (authorization, OTP entry) are tracked as first-class, time-limited, attempt-limited actions.
Submission & reconciliation
Separate reporting & clearance workflows
Simplified (B2C) invoices follow ZATCA's reporting model; standard (B2B) invoices follow the clearance model. Each is handled by its own correctly-shaped workflow instead of one workflow pretending to fit both.
Idempotent submission, no blind retries
A retried submission with the same idempotency key never resubmits to ZATCA a second time. If an outcome can't be determined, it's reported as genuinely unresolved rather than guessed.
Three-layer reconciliation
Canonical invoice data, generated XML, and ZATCA's own submission response are reconciled against each other and against your commercial billing records.
Immutable, tenant-isolated archive
Every submitted invoice and its artifacts are archived with a hash chain, scoped so one organization's archive is never visible to another.