How a banking internship and a hard-hat camera ended up in the same company.

01Two cities, one classroom

Charles grew up between Strasbourg and Saarbrücken, the kind of cross-border childhood where the question "where are you from" never has a one-word answer. He read finance because the numbers were easier to argue about than politics, did the Erasmus year in Poland writing a thesis on how the energy transition was hitting Eurozone inflation, and landed an internship at Landesbank Saar working on cross-border infrastructure deals. He was good at it. He was also bored.

Zeff grew up in Leuven, started in industrial engineering at KU Leuven, spent the first two years learning how things break under load. Halfway through he realised the thing he actually wanted to build was software, not bridges. He switched to business engineering, graduated cum laude, did a semester in Uppsala, and signed up for the Data for Finance master's in Geneva because it was the only program that put finance and machine learning in the same room without pretending one was a footnote to the other.

We met in week one. The course was at Albert School in Geneva, on the Mines Paris track. The cohort was small enough that you ended up sitting next to the same people every day. By month two we were running each other's homework. By month four we were arguing about whether a bank's risk team should ever be allowed near a large language model.

02The two stories

The first story is Charles's. Over the summer between the two years of the master's, he spent three months in a corporate-finance team at Landesbank Saar. The deals were the kind that move slowly: industrial assets, cross-border tax structuring, the usual. What surprised him was not the work itself. It was the cost line.

On every mid-sized client, somewhere between €30,000 and €80,000 of the quarterly bill went to a senior consultant whose job, in practice, was to retype figures from PDFs into Word, then Excel, then a deck. Not analyse them. Retype them. The PDFs were from suppliers, energy providers, auditors, regulators. The figures were not secret. They were sitting on page 14 of a document the client had already received. But the regulator-facing report needed those figures in a specific structure, with provenance, in a specific format, signed off by the right level. So a senior consultant retyped them.

The bottleneck was not the analysis. It was the transcription. And it cost more than the analysis did.

The second story is Zeff's. He spent the same summer at Xenon 54 in Mechelen, an AI safety company building computer vision for construction sites. The product flagged missing helmets, missing gear, the kinds of small omissions that get someone killed in a year nobody can predict. The model worked well. The interesting part was watching it fail.

When the model could not see clearly, when the helmet was half-occluded or the light was wrong, it had two choices. It could refuse to answer, and the site supervisor would get a "low confidence, please verify" flag. Or it could guess, and pick the most-likely-looking answer based on patterns it had seen before. Most language models do the second thing by default. They do not say "I don't know." They invent something plausible and move on.

In a construction-site safety tool, this distinction is the entire product. In a regulator-facing sustainability report, it is the same.

03The conversation

We compared notes in October of the second master's year. Charles described the consultant retyping bills from a German chemicals supplier. Zeff described the model inventing helmets in a partially-obscured frame. The pattern was the same on both sides.

The expensive part of compliance work is moving structured figures out of unstructured documents and into a regulator-shaped output. A human can do it slowly and reliably. A language model can do it fast and unreliably. The combination most people were building, language model plus light human review, kept the speed but quietly lost the reliability, because the model's failure mode is to fabricate confidently and the reviewer's failure mode is to nod at confident-sounding output.

So we reversed the default. We make the model refuse rather than fabricate. Every figure that ends up in an Attera report has to be traceable back to the page of the document it came from, or it does not ship. The reviewer's job becomes adjudicating refusals, not catching hallucinations. That is a tractable workload. The other one is not.

04Why Belgium

The first deployment was always going to be Belgian. Zeff is from Leuven and the workstation that runs the local language model lives there, in an office we operate. Charles handles the customer side from wherever he is, but the documents themselves do not leave the country.

This was not a marketing choice. It was a technical one. The customers we wanted to serve are the accounting firms running this reporting on behalf of their clients, and the mid-cap groups filing under CSRD for the first time. Every one of them has a DPO who will ask, in the first meeting, where the documents are processed and which third-party AI providers see them. Most vendors answer with the name of an American hyperscaler and a one-page DPA. We wanted to answer with the address of a building.

So that is the answer. The building is in Leuven. The model file is on a disk we can show you on a video call. The one sub-processor on the path is Tailscale, for private network coordination, and it does not see the documents either. The full list is on the security page. It is one entry long. We made it one entry long on purpose.

05What we have built so far

The product reads PDFs, extracts every structured figure, cites each one back to the source page, and reconciles the result into a report a reviewer can actually check. It ships an A4 PDF, an XLSX, and an evidence pack with a SHA-256 manifest. What we sell today is the Operating Report for accounting firms, on commission statements, invoices, and the other recurring document shapes their clients send them. Those use cases are documented on the use-cases page.

What we have not built yet is also on the website, on purpose. SOC 2. ISO 27001. SSO. KMS. A bug bounty. The full ESEF issuer extension taxonomy. A REST API. We will start that work when paying customer demand justifies it. Until then we would rather be honest about what is here than vague about what is coming.

06The third founder

An engine that refuses to fabricate a figure is only half the job. The other half is knowing which figures a regulator actually wants, and what a CSRD or ESRS disclosure has to say to stand up. Neither of us owns that. Julia Nitz does.

Julia joined as the third founder in the summer of 2026. She has run ESG programmes inside real companies, so she knows the point where sustainability reporting stops being a spreadsheet exercise and becomes a judgment call, and she named the gaps we build against: representing the ESG taxonomy properly, supporting IFRS, and linking the ESG data back to the financials. She took equity and no salary, the same deal we did. She is the reason the CSRD side of this is credible rather than two engineers with an ESRS checklist.

07What comes next

The CSRD Omnibus pushed the next wave of first filings out to 2028. That is a long time to wait for revenue, and it is why we stopped leading with it. The transcription problem underneath it is not a 2028 problem: an accounting firm is doing it by hand this month, on a client's commission statements. So that is where we start, and the engine is the same one either way.

The fastest way to find out whether this works for you is the same way we have always done it. Book a demo. Bring a real document. We will run a pass on it while you watch.