Automated invoicing for subscriptions: issuing, payment, collection

If you sell a service on subscription (maintenance, accounting, software, courses), the start of every month looks the same: someone opens the subscriber list, issues the invoices one by one, emails them out, then goes through the bank statement to see who has paid. By automated invoicing we mean exactly this: issuing, sending and payment tracking happen on schedule, with nobody doing them by hand, and the team is left with only the exceptions.

It is not only time that is at stake. Invoices issued late get paid late. When issuing, payment and the record of money received are linked, you can see on any given day how much you are owed and by whom.

What a subscription means to the system

Before any code, we describe the subscription as a rule: the service, the price, the currency, the start date, the interval (monthly, quarterly, annual), the issue day, the payment term and the condition for stopping. These look like details, but this is where most of the exceptions sit: the subscriber who started mid-month, the one moving up to a bigger package, the one with a negotiated price.

Every exception gets a rule, not a note. When a package changes during the period, for example, you can invoice the difference pro rata or apply the new price from the next invoice. What matters is that you choose one, and that the system applies it to everyone in the same way.

The tax aspects (invoice or pro forma before payment, the exchange rate for prices in a foreign currency, invoice reversals) are for you to settle with your accountant, and we turn them into rules.

Issuing, card payment and reminders

We do not issue invoices in a parallel system. The document is created through an API (the interface through which one program takes commands from another) in the software your accounting team already works in, and submission to e-Factura, Romania’s national e-invoicing system, remains that software’s job.

Let us assume you have a few hundred subscribers who pay monthly. On the set day, the system goes through the active subscriptions and takes these steps by itself:

• Issuing: the invoice is generated with the subscriber’s details, the period and the payment term, then goes out by email with a link for card payment.
• Recurring payment: if the subscriber has given consent, the amount is collected automatically from the card saved with the payment processor.
• Reminders: one message before the due date, one on the due date and others afterwards, in the tone you choose.
• Failed payments: an expired card or one with insufficient funds means another attempt and a message with a link to update the card.
• Suspension: if the contract provides for it, access to the service is restricted after a number of reminders, with prior notice.

Matching incoming payments to invoices

Card payments match themselves: the processor confirms the transaction together with the invoice reference. Bank transfers are the difficult part: people pay two invoices in a single amount, write something other than the invoice number in the payment details, or pay from another company’s account.

We import the bank statement (the file exported from online banking or, where the bank allows it, a direct connection) and, for each incoming payment, look for the matching invoice by the number in the payment details, the amount, the tax identification code (CUI) and the payer’s name. Matches that are certain are marked as paid automatically. Uncertain ones appear in a list, with suggestions, and a colleague confirms them.

The result is an up-to-date statement of overdue amounts, broken down by age, without waiting for the month-end close.

Tools and connections in an automated invoicing project

The invoicing software: many of the programs used in Romania offer an API (SmartBill and Oblio are two examples) through which invoices can be created and payments recorded, sometimes only on certain pricing plans. If your software has no API, we talk about importing through files or about replacing it.

The payment processor: recurring payments rely on tokenisation, meaning that the processor keeps the card details and gives you an identifier with which you initiate the subsequent payments. The cardholder authenticates the first payment with their bank, and for the following ones what counts is the consent given at that point, which we keep as evidence.

The rest is custom code, usually in PHP with Laravel: the subscription records, the scheduled jobs that trigger issuing and the log of every action. The log answers a question you are certain to be asked: why did this subscriber receive this invoice.

The duplicate invoice, the invoice after cancellation and other mistakes to prevent

The most expensive mistake is the duplicate invoice, or the one issued after the subscriber has cancelled. That is why every invoice issued has a unique key (subscription plus period), and the system refuses to issue a second time for the same pair. We do the first run as a dry run: the list of invoices that would be issued, checked by you, with no document created.

After go-live, a few simple indicators show whether the system is doing its job:

• Invoices issued on time against those that needed manual intervention.
• Incoming payments matched automatically against those confirmed by a person.
• Failed recurring payments and how many of them are recovered after a retry.

This is a typical project description: it shows how we usually approach this kind of work and does not present a project carried out for a particular client. Every real project starts from your company’s situation, and the stages, timescales and price are agreed after the initial discussion.