FREDERIK DANEELS
← Previous case Back to main page Next case →
CASE05

One enrollment form, five kinds of buyer, and not one invoice made by hand.

TALLY· MAKE.COM· MOLLIE· BILLIT· GOOGLE SHEETS· GMAIL

My client runs a training institute. Their courses run for weeks and cost around three thousand euro a seat. I connected their Tally enrollment form to Mollie for payment and Billit for invoicing, so that every enrollment stopped being a small administrative project and became a form submission.

5different routes through a single form
4automations working as one system
~180steps that used to be someone's morning
0invoices raised by hand

The problem

A form that collects answers is not a system that collects money.

They already had an enrollment form on their website. It did exactly what forms do: it caught the answers and stopped there. Everything that turns an answer into a paid, invoiced, confirmed student was a person, working through the same chain again for every single sign-up.

  1. Read the entry and work out who this is: a private buyer or a company, and in which country.
  2. Look up in the price sheet what that course costs on that date, with or without the early-bird discount.
  3. Create the customer in Billit with the right VAT status.
  4. Raise the invoice, VAT included for private buyers, excluded for companies.
  5. Send the confirmation with the invoice attached.
  6. For a company, deliver the same invoice again over Peppol.
  7. For someone paying in three parts, remember to come back for parts two and three, months later.
  8. Write all of it into a spreadsheet so anyone can see who has paid what.

Eight steps, every time, on a sale worth around three thousand euro. Eight places to make a small and expensive mistake.

Why it was not a simple job

The order of operations changes with the buyer.

A form that makes an invoice is a small build. This one does not make one invoice. Two answers on the form, who is buying and how they want to pay, decide the entire sequence that follows. A private buyer pays before the invoice exists. A company gets the invoice before it pays anything. Someone paying in three parts needs a payment plan that is still running two months later.

So the automation does not have a flow. It has five, and it picks one.

ROUTE 01

Private buyer, paying in one go

Pays first. The invoice and the confirmation follow the payment, not the form.

  1. Tally
  2. Mollie link
  3. Paid
  4. Billit invoice
  5. Confirmation
ROUTE 02

Private buyer, paying in three parts

Pays the first part now. The next two are scheduled and collect themselves, a month apart.

  1. Tally
  2. Mollie plan
  3. Part 1 paid
  4. Full Billit invoice
  5. 2 parts auto-collected
ROUTE 03

Company in Belgium

No payment link. The invoice goes out first and gets paid by transfer, the way companies actually pay.

  1. Tally
  2. Company looked up
  3. Billit invoice
  4. Peppol
  5. Confirmation
ROUTE 04

Company in the Netherlands or Luxembourg

Same shape, different tax. The country and the VAT number on the form decide how the invoice is raised.

  1. Tally
  2. VAT number read
  3. Cross-border Billit invoice
  4. Peppol
  5. Confirmation
ROUTE 05

The free introduction evening

Nothing to charge and nothing to invoice, so the automation skips both instead of raising a zero-euro invoice.

  1. Tally
  2. Recognized as free
  3. Logged in Sheets
  4. Confirmation

Five routes. The person filling in the form sees one form.

What I built

Tally to Mollie to Billit, with nobody in between.

Concretely: the Tally form posts straight into Make.com. Make.com checks the price against their own Google Sheet, then either creates a single Mollie payment or a Mollie subscription for a three-part plan, finds or creates the customer in Billit, raises the Billit invoice with the right VAT treatment, sends the confirmation with the invoice attached through their own Gmail, and writes the result into the sheet. When Mollie reports that money has landed, a second Make.com scenario books it off against the Billit invoice and updates the sheet again.

Four connected scenarios, around 180 individual steps. They already paid for all six of these tools. I did not replace anything. I made them talk.

The Tally enrollment form feeds Make.com. Make.com checks every price against the client's own price sheet, then splits into five routes that drive Mollie for payment, Billit for invoicing, Gmail for the confirmation, and Google Sheets for the overview. The price sheet A tab in their own Google Sheet. The only source of a real price. Tally form The enrollment form. Make.com Reads the answers, verifies the amount, picks the route. ~180 STEPS · 4 SCENARIOS CHECKED ON EVERY SINGLE ENROLLMENT 5 ROUTES Mollie One payment, or a plan of three parts. Billit Invoice raised, paid off, sent over Peppol. Gmail Confirmation from their own address. Google Sheets One row per student, one per payment.

The client keeps one spreadsheet. They fill in the top box and read the bottom one. Everything between the two runs without them.

The part I care about most

The number in the browser is not the number on the invoice.

A form has to show someone the price before they click pay. That number is worked out in their browser, which means it can be edited on the way out. Left alone, an enrollment could arrive claiming a three thousand euro course costs one euro, and a naive automation would open a valid Mollie payment link for it and raise a real Billit invoice to match.

So it does not trust the form. Before anything is charged, every enrollment is checked against the client's own price sheet: this course, on this date, with the early-bird discount that applies today. If the two numbers agree, it continues. If they disagree, it stops, mails the client both numbers with the name and the course attached, and sends the visitor to a page saying someone will be in touch.

The amount submitted by the Tally form and the amount in the client's price sheet are compared. If they disagree the enrollment is stopped and the client is emailed. If they agree, the Mollie payment link and the Billit invoice are created at the verified price. FROM THE BROWSER What the Tally form says FROM THE PRICE SHEET What the Google Sheet says Do they match? NO YES Stopped, and flagged The client gets a mail naming both numbers. Mollie link and Billit invoice Both at the verified price, never the sent one.

The automation would rather stop than guess. A held enrollment costs a phone call. A wrong invoice costs a lot more.

The route that used to hurt

Three thousand euro, split in three, without three follow-ups.

Paying in parts is the option that sells the course and creates the admin. One student choosing it used to mean a payment to remember in October and another in November, plus two more moments to book off against an invoice raised back in September.

Now the first part is charged at enrollment and the other two are scheduled as a Mollie subscription. Each one collects itself and, as it lands, gets booked against the same single Billit invoice. The split is worked out so the three parts add up to the full price to the cent, with the odd remainder carried in the first payment rather than left to rounding.

At enrollment Part 1 Charged immediately. Carries the remainder so the arithmetic lands exactly.
One month later Part 2 Collected automatically. Booked off against the same invoice.
Two months later Part 3 Collected automatically. Invoice closes itself.

One invoice for the full amount, three payments booked against it. The correct way round for the books, and the way nobody does it by hand.

What changed

The work did not get faster. It stopped existing.

Every enrollment gets the same paperwork

Same invoice, same VAT treatment, same confirmation, whether it arrives on a Tuesday morning or at eleven at night during a launch week.

Nothing gets chased

Installments collect themselves and book themselves off. Company invoices go out over Peppol the moment they are raised.

The overview is always current

One row per student, one row per payment, written as it happens. Nobody types into it and nobody has to trust that it was updated.

What they own now

A new course date is a row in their spreadsheet, not a call with me.

The price, the early-bird amount, the deadline it expires on, and which product it bills against all live in a sheet the client already uses. The automation reads it fresh on every enrollment, so what they change applies to the next sign-up. There is nothing to sync, nothing to send over, and no waiting on me to edit a number.

Two things still come back to me: an entirely new kind of course, and a new way of paying. Everything else is theirs. That is deliberate. An automation nobody but its builder can change is not an asset, it is a dependency.

Is one of your sales worth more than the process behind it?

If a sign-up, a booking, or a signature still turns into a chain of manual steps at your end, that chain is where the money and the mistakes are. Book a free audit call and I will map it with you.

Get your free audit call →
← Previous case Back to main page Next case →