From tracking project time for multiple clients, to automated invoice, to payment.

This is not a discipline problem. He is disciplined enough to log time on the day he works it, for six clients, without being asked. The problem is that logging an hour and billing an hour are two completely different jobs, and only one of them is interesting.

So the hours were always perfect and the invoices were always late. Which is an expensive way round, because the invoice is the only one of the two that brings money in.

An hour in Clockify knows what it was, when it happened and who it was for. It does not know what it is worth. That lives in the invoicing system, in a different product for every client, because no two of these contracts bill the same way. One is invoiced at zero percent VAT. One bills travel on top of the hours. One bills travel by the trip rather than by the hour. So "take the hours and make the invoice" is really six different sums that happen to start from the same export.

And then there is time itself. An automation that runs on a schedule has to know exactly which hours belong to the invoice it is making, and the edge of a month is a lot sharper than it looks.

Concretely: on a fixed day each month, Make.com asks Clockify for a summary of the month just gone, grouped by client. It walks that summary one client at a time. For each, it pulls the individual time entries back out of Clockify so it can count the separate visits as well as total the hours, then creates the invoice in Billit against that client's own customer record and their own products: hours on one line, travel on another where the contract has it. The invoice is dated the last day of the month it covers, carries a thirty day term, is titled with the client's name and the month, and leaves Billit the way his invoices always did.

Thirty-one steps, one scenario, once a month. He already had Clockify and he already had Billit. Nothing new was bought and nothing was replaced.

This is the quiet trap in every scheduled invoice, and it is the reason I would not just point the automation at "recent hours" and let it run. If a monthly job looks backwards thirty days from the day it happens to run, its window drifts. It clips off the start of the month it is meant to bill, and it reaches into the month it is not meant to bill yet. Run it twelve times and some hours get invoiced twice while others are never invoiced at all.

Nobody catches that quickly. Everything looks fine, the invoices look ordinary, and the error is a slow leak in both directions at once. So the scenario never works from today. It works out the first and the last day of the month just gone, and asks Clockify for that and nothing else. The invoice is then dated the last day of the period it actually covers, which is also what makes it sit in the right month in his books.

Two hours on site in one visit and two hours on site across two visits are the same hours and a different invoice, because he drove out twice. A total cannot tell the difference between those. Only the individual entries can.

So for every client the scenario goes back to Clockify a second time and pulls the entries themselves, not just the summary. The hours come off the total. The trips come off the count. Then each goes onto the invoice as its own line, in the shape that client's contract actually has.

What his work is worth lives in Billit, next to his bookkeeping, and changing a rate there changes the next invoice without anybody opening the automation. What he tracks and how he labels it lives in Clockify. Both were his before I arrived.

Adding a client is not. Each of the six contracts is wired as its own path through the scenario, which was the fast way to ship against a client list that changes about once a year. It is also the honest limit of this build: a seventh client does not get invoiced until I put them in. The version that does not have that limit reads his client list out of Clockify and loops over whatever it finds, so a new client bills itself the first month it has hours. That is the rebuild this deserves, and I would rather write that down here than let it look like a feature.