Issue invoices with Fakturoid or iDoklad

The goal: hand the “raise the invoice” step to your automations. When an order is approved, a job finishes, or the month ticks over, a flow issues the real invoice in your invoicing system — and later reads back whether it’s been paid, so a reminder only goes out while money is still owed.

Routario connects to two Czech invoicing systems today: Fakturoid and iDoklad. You bring your own account; your invoicing data stays between that account and your Routario.

Beta

These integrations are in Beta. Connect a real account and try a single invoice end-to-end before you point a live billing flow at them.

Step 1 — Connect your invoicing account

Go to Settings → Connections → Apps and open the Invoicing & Payments section. Pick Fakturoid or iDoklad and paste the API credentials from that system:

• Fakturoid — in Fakturoid, go to Settings → User account → API and create a Client ID and Client Secret. Paste both here, plus your account slug (the name in your Fakturoid address, app.fakturoid.cz/your-slug).
• iDoklad — in iDoklad, go to Settings → API and create a Client ID and Client Secret. There’s no account name to enter — your agenda is tied to the credentials.

Click Connect. Routario runs a read-only check against your account and shows the account name once it succeeds — nothing is created. Your credentials are stored encrypted and never shown again; only the account name and connection status appear afterwards.

Note

The invoicing steps below only appear in the flow palette (and as agent tools) once the account is connected. If you don’t see them, connect the account first.

Step 2 — Issue an invoice from a flow

Add a Create invoice step — Create invoice (Fakturoid) or Create invoice (iDoklad). You give it the client and the lines; it resolves (or creates) the client in your invoicing system’s address book and issues the invoice.

The fields you’ll set most often:

• Client name — the customer’s company name. Add their registration number (IČO) when you have it; matching by IČO is more reliable than by name.
• Lines — a list of items, each {name, quantity, unit_price, vat_rate}. Unit prices are entered without VAT.
• Due / maturity — days until the invoice is due (optional; blank uses the account default).

Never double-invoice: the idempotency key

Every Create invoice step takes a stable identifier for the invoice — this is the one field that keeps a re-run from issuing the same invoice twice:

• Fakturoid calls it the idempotency ID (custom_id).
• iDoklad calls it the order number (order_number, up to 20 characters).

Before creating anything, the step checks whether an invoice with that identifier already exists. If it does, the step returns the existing invoice instead of issuing a new one. So if a flow re-runs — a retry, a re-processed email, a scheduler firing twice — the customer still gets exactly one invoice.

Choose a stable key, not a timestamp

Give the idempotency key something that identifies the business event, not the moment it ran — an order id like order-1042, or a period key like 2026-07-rent-u3. A timestamp or a random value defeats the whole point: the next run won’t recognise it and will invoice again.

The step reports back created: true when it issued a new invoice, or created: false when it returned one that already existed — plus the invoice number, its total, and (for Fakturoid) a link to the invoice. Capture the step’s output and you can reference {{ create_invoice.invoice_id }} downstream.

Step 3 — Check whether an invoice is paid

Add a Get invoice step to read one invoice’s current state — most usefully, whether it’s been paid. Identify the invoice by the id you captured when you created it, or by the same idempotency key you set:

• Get invoice (Fakturoid) — look up by invoice_id, custom_id, or the invoice number.
• Get invoice (iDoklad) — look up by invoice_id or order_number.

Get invoice has two outgoing paths — found and missing — so you can branch on “no such invoice” without a separate condition step. On the found path, paid tells you whether it’s settled (with paid_on, the payment date).

This is what turns a blind reminder into a smart one: a follow-up flow fetches the invoice, and only sends the nudge while paid is still false.

List invoices for a digest

When you want a set of invoices rather than one — every unpaid invoice for a Monday-morning digest, say — add a List invoices step:

• List invoices (Fakturoid) filters by status (open, paid, overdue…) or an issue-date window.
• List invoices (iDoklad) has an unpaid_only toggle and can filter to one client.

Both return one page of invoices plus a has_more flag. Feed the list into a For each loop to act on every invoice — for example, send each customer a reminder.

A worked example: issue, then chase

Putting it together, a billing flow reads:

1. When an order is approved, Create invoice with custom_id (or order_number) set to the order id — so a duplicate approval can’t double-invoice.
2. Three days after the due date, Get invoice by that same id.
3. On the found path, Branch on paid: if it’s still false, Send email a polite reminder that references {{ get_invoice.number }} and {{ get_invoice.total }}.

The generic version of that chase — over a table of invoices rather than a connected system — is written up in Chase unpaid invoices automatically.

Where to go next

• Chase unpaid invoices automatically — the scheduled dunning pattern, step by step.
• Send email from a flow — write the reminder that goes out when an invoice is still unpaid.
• Template variables — how to reference a step’s output, like {{ create_invoice.invoice_id }}, further down the flow.