Sector
Fintech · Voice Invoicing
Market
Algerian artisans, freelancers and small companies
Engagement
Full product — conversational bot, AI extraction, document engine, billing, landing page
Status
Live subscription product · 2026
The situation
Most commercial activity in Algeria is documented badly or not at all, and not because the people doing it are careless. A tiler, a printer, a freelance developer or a small trading company needs to issue a devis to win a job and a facture to get paid, and both documents carry legal requirements: a fiscal identification number, the tax situation, the stamp duty line where it applies, the amount written out in words, and continuous numbering with no gaps. Accounting software exists, but it is priced and shaped for a company with an accountant, and it assumes someone will sit at a desk and fill in a form.
What that person actually has is a phone, a WhatsApp or Telegram habit, and thirty seconds between jobs. Selling and negotiating already happen in chat. The invoice is the one artefact that forces a context switch out of the conversation into a spreadsheet template that someone made once and everyone has been copying and editing ever since, which is exactly how numbering ends up with gaps and how the same client appears three times with three spellings.
There is also a structural detail that off-the-shelf tools get wrong for this market. Under the Algerian auto-entrepreneur regime a business has a fiscal identification number but no commercial register entry and no statistical identifier. Software that treats those as mandatory fields either blocks the user at signup or prints empty labelled boxes on a document that then looks unprofessional. Getting that single branch right is the difference between a tool a self-employed Algerian can use and one they abandon on the first screen.
What made this hard
The interface had to be something already installed
Asking this user to download an app, create an account and learn a dashboard is asking them to not use the product. The interface had to be a chat they are already in, which means every capability (onboarding, business profile, document creation, corrections, payment, quota) has to be expressible as messages and buttons rather than as screens.
A language model must not be trusted with the document
An invoice is a legal and financial artefact. Totals must be arithmetic, not plausible. Numbering must be sequential, not generated. The amount in words must match the amount in figures. Any architecture where the model writes the final document is an architecture that will eventually produce a confidently wrong invoice, and one is enough to lose the customer.
Compliance is a branch, not a checklist
The required fields on an Algerian invoice depend on the issuer's legal status. An auto-entrepreneur has no commercial register number and no statistical number; a company has both. Value added tax, exemption mentions and stamp duty behave differently again. The data model had to branch on status from the first onboarding question rather than collect everything and hope.
The automation platform could not be the database
The document engine was first built on a no-code automation platform, whose built-in data stores are capped at a few megabytes for an entire organisation, on the order of a thousand documents. That is fine for one business and structurally impossible for a paid multi-tenant product, and the same platform's operation budget put a ceiling on annual document volume.
Typography that a printed document exposes
French commercial documents have typographic rules (elision apostrophes, hyphenated compounds, thin spaces before certain punctuation) and a printed A4 page shows every violation. An early prompt instruction to avoid a particular character was over-generalised by the model into dropping apostrophes and hyphens entirely, producing invoices that read as broken French.
How we approached it
We settled the architecture on one sentence: the web application is the mind, the automation engine is the muscle. The application owns everything that must be durable, multi-tenant and correct — user accounts, subscriptions, business profiles, onboarding state, quota, document storage and the payment flow. The automation engine owns the message-to-document transformation: understand the request, produce the fields, render the page. Anything stateful that lives only in the engine is a liability; anything computational that lives only in the application is unnecessary weight.
The second principle is that the model decides and the renderer produces. The language model's job is to turn a spoken sentence into structured intent: who the client is, what the lines are, which document type. Nothing else. Every number, every total, every amount in words, every piece of typography and every escape character is produced by deterministic code. That boundary is what makes a voice-driven invoice trustworthy, and it is the single decision most responsible for the product working.
A working document engine for one business
We first built the whole thing as a single-tenant document engine driven from chat, producing devis, factures, proforma invoices, purchase orders, delivery notes, contracts, receipts and credit notes as printable A4 pages. It went into real use immediately, which is how the compliance details and the typography problems surfaced before there were any customers to lose.
Replacing model output with deterministic rendering
We rebuilt the renderer around executable code rather than a long chain of no-code modules and model calls. Number-to-words in French, line and total arithmetic, typography normalisation and HTML escaping all became deterministic functions, collapsing the render step to a handful of operations and removing an AI call from the critical path of every document.
The pivot to a multi-tenant product
We moved ownership of users, subscriptions, business profiles and document storage into a web application with a proper database and blob storage, and reduced the automation engine to the front-end connector and the generator. The bot's chat surface stayed identical for the user while everything underneath it changed.
Onboarding, identity and billing
We built a conversational onboarding state machine covering chat language, document language, legal status, issuer details and uploaded stamp and signature images, plus a subscription flow paid in dinars on domestic cards and a code redemption that links a paid account to a chat.
Styles, follow-ups and reporting
We added four document styles the user picks, automatic follow-up reminders for documents that are due, search across past documents, quote-to-invoice conversion, and a periodic activity summary, the things that turn a document generator into a small commercial workflow.
What we shipped
Voice and conversation
- Send a voice note or a text message describing the sale
- The assistant extracts client, lines, quantities and amounts as structured fields
- It confirms amounts before creating any financial document
- Corrections made by simply saying what is wrong
- Interface language and document language chosen independently
- Full command menu and button grid, no typed syntax to learn
Documents and compliance
- Devis, facture, proforma, purchase order, delivery note, contract, receipt and credit note
- Continuous legal numbering assigned server-side with no gaps
- Fiscal identification handled per legal status, with empty issuer fields hidden rather than printed blank
- Tax, exemption mentions and stamp duty applied by rule
- Amounts written out in words in correct French
- Four document styles: classic, minimal, modern and compact
- A4 PDF output ready to print or send
Account and workflow
- Conversational onboarding that builds the business profile once
- Stamp and signature uploaded as photos and composited onto the document
- Quote to invoice conversion in one step
- Search and tracking across past documents
- Automatic reminders on documents that fall due
- Subscription tiers billed in dinars on domestic cards, with quota enforced per plan
Engineering decisions
The choices that shaped the build, and what each one traded away.
The application is the mind, the automation engine is the muscle
Users, subscriptions, business profiles, onboarding state, quota and stored documents live in a managed Postgres database with blob storage behind the web application; the automation platform keeps only the message-to-document transformation. The forcing function was a hard limit: the platform's built-in data stores are capped at a few megabytes organisation-wide, roughly a thousand documents, and its annual operation budget caps document volume independently. The trade-off is a distributed system with a network hop and an authenticated contract between the two halves instead of one codebase, accepted because the alternative was a paid multi-tenant product on a database that cannot grow.
Deterministic rendering, never model-generated documents
The model produces structured intent; a rendering function produces the page. French number-to-words, line and total arithmetic, typography normalisation and HTML escaping are all code. This was not theoretical: an instruction telling the model to avoid a particular character was over-generalised into dropping apostrophes and hyphens, so printed invoices read as broken French, and a missing escape meant an ampersand in a client's name broke the document outright. We fixed the prompt and then fixed the renderer, because only the renderer is a guarantee. The trade-off is rigidity: every new field, legal mention or currency rule is a code change rather than a prompt edit, and the model cannot improvise around a case nobody implemented. On a document whose numbers are legally binding, that rigidity is the point.
Document numbers are assigned after the assistant has answered
The assistant never sees a document number, because numbers are allocated by the creation step after the conversation turn is complete. That protects the one thing that must be gapless and sequential from ever being generated by a model. The consequence is that any action needing a number has to accept an empty one and resolve it server-side, so editing works by resolving the most recent document rather than by asking the user or the model to name it: a small amount of extra server logic in return for numbering that is structurally correct.
Legal status as a first-class branch in the data model
Onboarding asks legal status before it asks for identifiers, because under the auto-entrepreneur regime there is no commercial register number and no statistical identifier. Those fields are not collected, not required, and any empty issuer field is hidden by the template rather than printed as an empty labelled box. It costs a branch in the profile model and in the renderer, and it is the difference between a document that looks issued by a real business and one that looks like a half-filled form.
Stamp and signature composited with a blend mode, not background removal
Users photograph their stamp and signature on paper, which means a white background. Rather than run background removal, the renderer composites those images with a multiply blend so white disappears against the page and only the ink remains. It is a one-line CSS decision that removed an entire image-processing dependency and its failure modes. The limitation is real: it assumes a light document background, which holds for every invoice this product prints.
The outcome
Facturili is live as a subscription product with real invoices going out through it. A user starts the bot, answers a short conversational onboarding, and from then on issues compliant documents by talking: a voice note describing a sale comes back as a numbered A4 PDF carrying their fiscal identity, their stamp and their signature, in the style they picked. There is no app to install and no dashboard to learn, because the interface is a chat they already had open.
The architecture is what makes that sustainable rather than a demo. The parts that must be durable and multi-tenant — accounts, subscriptions, business profiles, stored documents, quota — sit in a proper database behind the web application, and the automation engine does what automation platforms are genuinely good at: connecting a chat surface to a generation pipeline. Moving that boundary was the difference between a clever single-user workflow and a product that can take money from strangers.
The compliance work is the least visible and most valuable part. Legal status branches the entire document. Numbering is sequential by construction rather than by the model's good behaviour. Amounts in words are computed, not written. Tax and stamp duty are rules, not reminders. A user who does not know which mentions their status requires simply never sees the question, and the document is right anyway — which is the only version of compliance that actually gets used.
8
Document types
Devis, facture, proforma, purchase order, delivery note, contract, receipt and credit note, each with its own required fields and numbering series.
4
Document styles
Classic, minimal, modern and compact, chosen by the user and applied by the deterministic renderer rather than by the model.
0
Apps to install
The entire product runs inside a chat client the user already has; onboarding, document creation, corrections, quota and support are all conversational.
CIB · Edahabia
Payment rails
Subscriptions are billed in dinars on Algerian domestic cards, so no foreign card or international payment method is required.
Honestly
The open frontier is dialect. The transcription path is currently strongest in French and English, and the English route is the one verified end to end; heavy Algerian darija dictation is the case we are least willing to make claims about. The design mitigates it deliberately rather than pretending otherwise: a voice note never creates a financial document directly. The assistant restates the client, the lines and the totals and waits for confirmation before anything is numbered. When transcription is uncertain, the failure surfaces as a question rather than as a wrong invoice.
The split architecture also carries a maintenance cost we accepted with open eyes. Two systems mean a contract between them, an authentication step at the seam, and a class of bugs that appear nowhere else: hand-editing generated automation blueprints can silently lose invisible characters such as non-breaking spaces, which is exactly the kind of defect that only shows up on a printed page. We keep the boundary because it buys a real database and a real subscription model, and we keep the renderer deterministic because that is the part where being wrong actually costs the customer money.
Frequently asked
Can I create an invoice by voice in Algeria?
Yes. Facturili works entirely inside Telegram: you send a voice note describing the sale (the client, what was sold, the amounts) and receive a numbered A4 invoice or quote as a PDF. The assistant confirms the amounts with you before creating any financial document, so a misheard figure becomes a question rather than a wrong invoice.
Is an invoice generated by AI legally valid in Algeria?
The document is not written by the AI. The model only extracts the details of the sale into structured fields; the invoice itself is produced by deterministic code that applies the numbering series, the tax and stamp duty rules, the required mentions for your legal status and the amount in words. That is what makes the output dependable rather than plausible.
Does it work for auto-entrepreneurs without a commercial register number?
Yes, and this is handled deliberately. Onboarding asks your legal status first, and under the auto-entrepreneur regime the commercial register and statistical identifiers are simply not requested, not required, and not printed. Empty issuer fields are hidden by the template rather than shown as blank labelled boxes, so the document still looks properly issued.
How much does invoicing software cost in Algeria?
Facturili is sold as a monthly or annual subscription priced in dinars and paid with a domestic CIB or Edahabia card, with a document quota on the entry tier and unlimited documents above it. It is deliberately priced for a self-employed person or a small business rather than for a company with an accounting department.