How I Added Recurring Invoices to FakturHuko

The recurring system needed its own UX, its own draft handling, separate email settings, and also several safeguards against errors that can show up unpleasantly in live operation.

The core of the feature is built on templates. Each one has its own period, next issue date, automatic sending status, and a linked draft of the next invoice. It was important to me that the user could see not only the template itself at a glance, but also what would happen next.

A big topic was the first send. One universal process seemed simple at first, but in practice it caused confusion. It was better to clearly split the actions into issue and send immediately, or schedule sending later. For a feature like this, it is better to guide users through two clear paths than through one smart form.

Separating the template from the specific draft was also important. A recurring template must not be the same thing as the invoice that is about to be sent. The draft must be editable separately without breaking the original settings for the whole series. This also makes it possible to handle one-off exceptions without disrupting the next repetition.

The behavior of items with a zero or missing price was also interesting. In the template, they make sense as prepared rows for later completion, but they should not appear in the PDF, print view, or public preview. It was therefore necessary to separate the internally stored structure from what the client actually sees.

Email templates turned out similarly. For regular invoices, the default client settings are often enough, but with recurring invoices that stops working. One client can have multiple different series, and each may need different email text or different attachment behavior. That is why it makes more sense to keep this setting directly at the level of a specific recurring invoice template.

In the end, the usual operational details also came into play: time zones, localization, and security. It is not enough to store only the date, because the correct time must also make sense from the client’s perspective, and they may be in a different time zone. Automated processes are exactly where you find out fastest whether the data model is truly clean.

In the end, it was confirmed that recurring invoices are not just “an invoice + cron.” Once the whole process needs to be usable and reliable, UX, draft states, emails, and a lot of small details around them all start to matter. I have a feeling I could easily spend a few more sessions on it, tweaking and tweaking and tweaking.