September 1, 2026 marks the effective start of France’s electronic invoicing reform . Every company must now be able to receive electronic invoices; large companies and mid-sized enterprises must also issue them in this form. As often happens with this kind of change, I’ve seen plenty of commotion on social media. In an ironic bit of timing, the French tax authority itself disclosed unauthorized access to part of its information system in mid-August, while stressing that the incident was unrelated to the electronic invoicing system.

All of this reminded me of a small tool I wrote for NuCorder a few months ago.

Don’t worry, I’m not about to sell you an invoicing platform—that isn’t my business at all. Instead, I’d like to discuss a related, much smaller problem that affects nearly every company: the monthly chore of collecting supplier invoices before sending them to accounting.

Two people reviewing invoices and accounting documents

Photo: Mikhail Nilov / Pexels.

Half an hour lost every month

NuCorder is an online rehearsal platform for musicians where I work as founding CTO alongside my consulting practice. The project is run by a small company, Ugly Cat, formed by its three founders.

There is no accounting department or office manager: we do everything ourselves. So every month, I log in to our suppliers’ various websites, download their invoices one by one, and send them to our accountant.

There is nothing particularly difficult about it. It is simply repetitive, time-consuming, and boring enough to keep slipping toward the bottom of the pile. In practice, everything is always sent on time: the volume is modest, and Jean-Noël, our president, reminds me if I fall behind. But like any obligation, the longer I wait, the more likely I am to deal with it in a rush.

Like many administrative chores, this task is predictable, always follows the same pattern, and requires almost no human judgment. From a developer’s perspective, it is exactly the kind of work a small tool can handle without requiring hours of development or turning into a huge project.

One command to rule them all

bills-collector is the name of the tool I eventually wrote for NuCorder.

In practical terms, it is a Go project of roughly 2,000 lines of code, packaged as a CLI—a program without a graphical interface.

When it starts, the command loads a configuration file (a small project is no excuse to commit secrets), determines the previous month, then queries the APIs of suppliers that provide one.

go 
// BillType represents the category of a bill
type BillType string

const (
	// BillTypeExpense represents bills the company pays
	BillTypeExpense BillType = "expense"
	// BillTypeRevenue represents bills the company issues to customers
	BillTypeRevenue BillType = "revenue"
)

// Bill represents a downloaded bill/invoice
type Bill struct {
	Provider    string
	BillType    BillType
	Date        time.Time
	Filename    string
	Content     []byte
	ContentType string // "pdf", "csv", etc.
}

type BillProvider interface {
    FetchBills(ctx, month) ([]Bill, error)
    GetName() string
    IsEnabled() bool
}

The rest of the code is not particularly interesting here, and I would rather not publish the exact list of suppliers and integrations NuCorder uses. The important idea lies in this interface: every supplier exposes the same way to retrieve its invoices, allowing the program to process them uniformly.

The operation takes a few seconds and creates a file tree that I only need to check, zip, and send to accounting. Doing it manually easily took twenty minutes, assuming I was already logged in to every service and had my bookmarks ready.

The tool is intentionally simple and does not try to cover every edge case, particularly when a supplier has no usable API. I had no desire to embark on a lengthy reverse-engineering exercise and risk getting blocked along the way: the goal was to save time, not lose it.

Today, only two cases remain to be handled manually.

Output from bills-collector after collecting the invoices
The bills-collector command after a successful run

Why build a small custom tool?

Because for a company this small, the problem justifies neither another subscription nor infrastructure costs.

bills-collector has no graphical interface, user account, or monthly subscription. It is a small program I run when I need it, and it stops once its work is done.

Technically, the principle is fairly ordinary: a few calls to supplier APIs and a command-line interface to run them all. Go, my preferred language, is well suited to this kind of exercise: it makes it quick to produce a self-contained executable that is easy to deploy and rerun without installing an entire environment around it.

This is obviously not a universal recommendation. For another need or another team, the right choice might be Python, JavaScript, PowerShell, or any other tool they already know. What matters is choosing the option that solves the problem simply.

Of course, a “small tool” does not mean “no maintenance”: an API or authentication method can change. Even so, the scope remains very limited compared with a full application.

For NuCorder, roughly two hours of development and validation were enough to eliminate most of a monthly task. It is precisely because the problem is modest that the solution can be modest too.

Use AI to build the tool, not to run it

In the tech world, an echo chamber can sometimes make it seem as though AI belongs everywhere and should handle every automation. I don’t think that is necessary, and I see a growing risk of dependency in it—not to mention the ethical questions surrounding the datasets used to train these models.

I see a different opportunity instead: tackling needs that are never quite a priority, not because they do not exist, but because something else is always more urgent.

Generative AI can now help us prototype and build small, targeted tools very quickly, provided we already know what we want to do and how to approach it. In a case like this, I see little value in asking a model to solve exactly the same problem every month, introducing a recurring cost, another dependency, and the risk of getting a different result from one run to the next.

AI can therefore reduce the cost of creating small tools without becoming a permanent dependency at runtime. For many mechanical tasks, this is a leaner—and often more suitable—approach than adding an agent where a few lines of deterministic logic will do.

What I take away

bills-collector is not a spectacular project: it took about two hours of work to remove a twenty-minute task that came back every month. That is exactly what makes it interesting.

We readily think of technology as a way to solve big problems: launching a new application, redesigning an architecture, deploying a platform, or introducing AI. We less often think of using it to remove the small frictions that quietly accumulate in a company’s daily work.

Not all of them deserve to be automated. But when a task is repetitive, predictable, and requires almost no human judgment, it may be worth asking whether a few hours of development will cost less than repeating it for years.

The right tool is not necessarily the most complete or impressive one: it is the one that meets the need with the least possible complexity.

Sometimes, it’s just a command.

Do you have this kind of task in your company?

Manual collection, files to consolidate every week, exports to reprocess, or an internal process that takes time without really adding value?

This is exactly the kind of problem I work on at Cabestan: understanding the need, identifying what is genuinely worth automating, and building the simplest solution that addresses it.

If this article reminded you of a chore that you or your teams still repeat by hand, get in touch.

Let's talk