We build fleet-management software for professional car and utility-vehicle rental companies (Lexio). A surprisingly large chunk of what our customers need isn't glamorous product work — it's correctly computing the taxes and paperwork tied to owning and renting out vehicles in France. We ended up extracting that logic into standalone open-source packages, and wanted to share why and how.
Two nasty examples
- TVS (the annual tax on company-owned tourism vehicles), recently folded into a broader vehicle-tax regime — the rules shifted again this year, and the official simulators handle mixed fleets poorly.
- Avantage en nature véhicule — the benefit-in-kind calculation for company cars, which has two different regimes depending on whether the vehicle entered service before or after February 2025, plus a "forfait" vs "réel" choice that a lot of payroll tools get subtly wrong.
We had already built correct, tested implementations of both inside our product. Rather than leave that logic locked in our monolith, we pulled it into small, dependency-free TypeScript packages and open-sourced them.
What's in there
Four repos so far:
- simulateur-tvs — the annual company-vehicle tax engine
- calcul-avantage-en-nature — benefit-in-kind calculator (forfait/réel, pre/post Feb-2025 regimes)
- contrat-location-vehicule — a rental-contract generator (pro-to-consumer, pro-to-pro, between individuals)
- lettre-contestation-amende — generates fine-contestation letters with the correct legal deadlines and grounds
Each one is standalone: no framework, no UI, just the business logic plus a test suite checked against the numbers published by the relevant French administration (URSSAF for benefit-in-kind, the tax code articles for TVS).
Why bother open-sourcing tax logic
Two reasons.
First, this kind of compliance logic rots fast. Tax brackets and regimes change every year, sometimes mid-year, like the benefit-in-kind reform did. Every SaaS that touches French fleet or payroll data ends up re-implementing a slightly-wrong version of the same rules. Publishing tested reference implementations means fewer people get it wrong, and if we get something wrong ourselves, someone can file an issue instead of a customer silently filing an incorrect return.
Second, isolating the logic made our own codebase easier to test and reason about. The extraction forced us to separate "what the calculation does" from "how our app happens to use it" — a good discipline whether or not you open-source the result.
The numbers
72 tests passing across the four repos as of this post, mostly regression tests built from real worked examples in official guidance docs, plus edge cases around fiscal-year boundaries and rounding.
Try it, break it
If you're building anything that touches French vehicle taxation or rental contracts, the repos are open for issues and PRs at github.com/lexio-rent-git. We built these for our own product (lexio.rent), but they should be useful standalone — let us know if they're wrong for a case we haven't tested.
Top comments (0)