In your head, an invoice is one sentence: ten hours of dev work for Várda Consulting. On screen it's a form: partner, line items, VAT rate, payment method, dates. The invoice is already finished in your head; you just have to click through the form.
Számlázz.hu and Billingo are everywhere, and people like them. The question isn't whether there's demand for invoicing, but why you still have to walk the same fields by hand. Hence the idea: instead of filling in a form, you just tell an assistant what you're invoicing.
There's a catch, though. An invoice isn't a chat message. It's a legal document the system reports to the Hungarian tax authority (NAV), and once issued there's no undo, only a formal reversal. For an invoicing AI, trust isn't a later feature; it's the foundation. That decides what gets built first.
What it is, and what isn't yet
The opening screen promises one sentence. Behind it today is the foundation: the Számlázz.hu integration, encrypted key handling, the invoice state machine, the full design system. What isn't built yet is the conversational layer itself, the part that turns the sentence into a draft invoice.
That order is deliberate. The conversational layer is the showy part, but the product's reliability rests on what sits beneath it.
The hard part is underneath the AI
The Számlázz.hu Agent API speaks XML, in a fixed field order, validated against an XSD. Hungarian VAT runs from 0 to 27%, plus the text codes (AAM, EUT, TAM and the rest) that all resolve to 0% for different legal reasons. Rounding is currency-aware: integers for forint, two decimals for euro and dollar. The most common error codes are each translated into a sentence a person can read, and the list grows. Then a taxpayer lookup against NAV's registry to confirm the partner is real.
This engine isn't flashy, but it's what has to work first. That part is done. It's also built to be provider-agnostic: Számlázz.hu first, Billingo next. So the layer above doesn't talk to the vendor directly; it works through its own internal interface.
Designing for trust
In the code the design system is called the midnight ledger: dark, warm, quiet. Something you sit with every day shouldn't shout.
Color is semantic, and I spend it sparingly. Amber for action and confirmation. Sage green for an issued invoice. Ochre for missing data. Red is reserved for one thing: the irreversible, meaning going live or a reversal. When red always means "this can't be undone," the interface stays credible.
Numbers are set in mono, so a tax number looks like a tax number. The preview card spells out net, VAT and gross for every line, so nothing is hidden before you commit. The assistant proposes; issuing is your call. Test mode is the default, so you can try it with no real invoice and no risk.
Motion carries the same voice. On the landing the assistant composes the invoice in front of you: it listens, types out the sentence, finds the partner, and the skeleton resolves into the finished preview — not decoration, but the very flow you'll see for real. Further down, sections arrive on a single quiet reveal; the goal is calm precision, not spectacle.
Under the surface
The Agent key stays encrypted at rest with AES-256-GCM and is decrypted only at the moment of the call; it never reaches the browser or the language model. Every invoice starts as a draft and moves through a state machine: draft → awaiting confirmation → issuing → issued or failed. Each transition is written to an append-only log. An idempotency key (account plus line reference) guarantees a retry never issues twice. That's the one mistake you can't make with a tax authority.
The stack: Next.js 16, React 19, Postgres with Drizzle, Better Auth. It runs on Railway, in the EU region.
What's next
The conversational layer: from a sentence to a partner, line items and VAT, then the same preview you saw above. After that, partner memory in the UI, invoice history, PDF generation and email, then Billingo.
That's why the language model comes last, not first. It's only safe to add once everything it could get wrong is already guarded.
The invisible part
The promise is one sentence: say the invoice, and the rest is handled. Most of the work is making that sentence safe to say.
Wiring a language model to an invoicing API is the easy part. The hard part is that here "the rest" includes a tax authority, and even so, saying the invoice should still be enough.
There's always a next level.
If you like what you see (whether you're building a product or a team) I'd love to hear about it.