Building Invoicey: AI at the edges, rules at the core

I invoice only a few clients each month. That should make invoicing simple.

It does not.

Sometimes I invoice as a freelancer, sometimes through an s.r.o. Each business has its own bank account, numbering rules, VAT setup, and visual identity. The volume is small; the number of details that must be correct is not.

I wanted to describe an invoice once—ideally where I was already working—and let the boring parts happen correctly. That became Invoicey.

The obvious first version was the wrong one

The tempting product was a chat box connected directly to a PDF generator. Type a sentence, let a model fill the gaps, download something that looks like an invoice.

But an invoice is not prose. It has legal parties, tax modes, dates, line items, totals, numbering, payment identifiers, and a lifecycle. The same values must survive into the PDF, payment QR, accounting export, email, and database.

So Invoicey started with the opposite architecture: AI at the edges, deterministic rules at the core.

The web form, JSON import, in-app AI, MCP, and Slack all converge on one validated InvoiceSchema. From there, ordinary code calculates totals, applies VAT rules, assigns numbers, derives status, and renders the files.

That boundary made the beginning less flashy. It made everything after it much easier to trust.

I wrote the rules before the dashboard

The repository began on 3 May 2026 with a product brief, domain model, architecture, roadmap, glossary, and sixteen decision records.

This was not documentation added after the interesting work. It was the first interesting work.

I defined three real scenarios: invoicing from more than one business, unusual on-behalf-of or self-billing cases, and issuing invoices through tools such as Slack or MCP. I also designed invoices as snapshots. If a client changes address next year, last year’s issued document must not silently change with it.

The same thinking shaped the status engine. An invoice is not “paid” because somebody changed a label; it is paid because a payment fact exists. Draft, issued, overdue, paid, and cancelled states are derived from the underlying dates.

1. 3 May 2026

   The rules became a working engine

   Schema, totals, numbering, status, Czech VAT, ARES lookup, PDF, SPAYD payment QR, ISDOC 6.0.2, and the first Slack experiment landed in one concentrated build.

2. 10 August

   The engine became an application

   I returned to build persistence, issuers, clients, the invoice editor, lists, dashboard, MCP tools, and a durable Slack agent.

3. 11–13 August

   The application became a platform

   OAuth, workspaces, invites, email, recurring drafts, historical import, in-app AI, multi-currency, Czech/English document rendering, API keys, security controls, and product hardening followed.

One source of truth, several entrances

The core now understands invoices, proformas, advance invoices, and credit notes. It handles Czech VAT modes, DUZP, supplies abroad, payment symbols, per-issuer numbering, multiple currencies, and Czech or English documents. ARES can fill company data from an IČO or name.

From the same validated data it produces a readable PDF, a SPAYD QR for Czech banking apps, and ISDOC 6.0.2 for accounting software. Issued artifacts are immutable; older PDF and ISDOC files can be imported without rewriting their history.

Around that core, Invoicey now has several ways in:

• a complete web workspace for issuers, clients, drafts, issuing, payment tracking, dashboards, and search;
• a structured JSON path and an in-app prompt-to-draft flow;
• local and remote MCP tools that can create, list, retrieve, email, and mark invoices paid;
• a Slack agent that links a Slack identity to the correct Invoicey workspace and keeps sensitive actions behind confirmation.

The important detail is what did not happen: these did not become four subtly different invoicing products. They share the same rules.

1.24.0

Current version

The latest release as of 13 August 2026.

178

Repository commits

Concentrated across five active build days since May.

1

Invoice contract

Every interface converges on the same validated schema.

The product changed quickly after the first post

When I first published this story on 11 August, authentication, email, recurring invoices, and database-backed MCP operations were still future plans. Two days later, that paragraph was obsolete.

Invoicey now supports Google and GitHub sign-in, multiple workspaces, members and invitations, linked accounts, session management, trusted devices, audit history, and personal API keys. Each workspace can have several issuer businesses while keeping clients shared inside the workspace.

Email delivery is implemented with PDF and ISDOC attachments, delivery events, overdue reminders, and suppression after bounces or complaints. Recurring schedules deliberately create drafts, not unattended issued invoices: automation prepares the work, but a person keeps the final legal decision.

The same principle shows up in Slack. An identity must be explicitly linked, still belong to the workspace, and use that workspace’s chosen issuer. Missing context fails closed instead of falling back to convenient demo data.

That is the most satisfying kind of progress: not only more features, but clearer boundaries around what the product is allowed to do.

Where it honestly stands now

Invoicey is deployed and usable, but it is still a private beta—not a finished public or paid SaaS.

The product surface is broad enough for real invoicing. The immediate work is now less glamorous and more important: apply and verify the latest database migrations in the correct order, repeat authenticated end-to-end tests, complete real email/import/Slack smoke tests, enforce CI and browser security policy, and finish the legal and commercial details required for a public launch.

Only after that do I want to return to larger features. Possible later work includes dual-language documents on one PDF, custom templates, bank-statement reconciliation, and AI token top-ups. Tax reporting may never belong here. I would rather keep Invoicey excellent at issuing and managing invoices than let it become a mediocre accounting suite.

The original problem remains the product test: describe the invoice once, verify it, and let every output agree.