Forem: Palks Studio

How I integrated Factur-X EN16931 into a PHP billing system — without a database or SaaS dependency

Palks Studio — Mon, 11 May 2026 10:17:35 +0000

Without a database, without a SaaS platform, without an ERP

When the French e-invoicing reform (RFE) started becoming a real deadline, I needed to make my billing system compliant.

Not by switching to a SaaS platform.

Not by plugging into an ERP. But by integrating the Factur-X standard directly into an existing PHP stack, deployed on a standard Apache server.

This article is about how I did it, what the standard actually requires, and what the real technical challenges were.

What is Factur-X, really?

Factur-X is a franco-german standard for structured electronic invoicing. It is built on two layers:

A PDF/A-3 file — not just a regular PDF, but a long-term archiving format defined by ISO 19005-3
An embedded XML file compliant with the EN16931 European standard, profile Comfort

The PDF is human-readable. The XML is machine-readable. Both are mandatory. One without the other is not Factur-X.

The standard is already required for public procurement in France and is progressively being adopted across the EU under the european VAT directive. It is not a french-only concern.

The VAT legal mentions — the part most developers miss

Generating a valid Factur-X file is not enough. The invoice itself must carry the correct VAT legal mention depending on the client's location. Getting this wrong is not a formatting issue — it is a fiscal compliance issue.

There are three cases when the issuer is based in France:

French client

The issuer is a micro-enterprise or not subject to VAT. The mandatory mention is:

TVA non applicable, art. 293B du CGI

No VAT is applied. No VAT column appears on the invoice. This mention must be present.

EU client (B2B with VAT number)

The transaction falls under the reverse charge mechanism. The client self-declares the VAT in their own country. The mandatory mention is:

Autoliquidation — TVA due par le preneur, art. 283-2 du CGI

VAT is forced to 0% on all lines. The mention replaces any VAT footer.

Non-EU client

The service is exported outside the EU. VAT exemption applies under export rules. The mandatory mention is:

Exonération de TVA — art. 262 I du CGI

Again, VAT is 0%. The mention is legally required on the document.

These three mentions are not optional notes. They are the legal justification for why VAT is absent or transferred. An invoice without the correct mention — or with the wrong one — can be challenged during a tax audit.

In my implementation, the correct mention is determined automatically based on the client's country ISO code and VAT number. The developer does not choose it manually. The system does.

The technical chain — how Factur-X is actually generated

The generation happens in two distinct phases, handled by two separate components. This separation is intentional — each phase has a different responsibility and a different technical constraint.

Phase 1 — Building the XML

The first component is a PHP script responsible for constructing the EN16931-compliant XML file.

It reads the invoice data — issuer details, client details, line items, VAT amounts, totals, payment terms — and maps each field to the correct EN16931 element. The profile used is Comfort, which covers the full set of fields required for B2B invoicing including VAT breakdown by rate.

A few things that matter here:

Amounts must follow strict decimal formatting — no rounding shortcuts
VAT must be aggregated by rate, not by line
The seller and buyer identifiers (SIREN, SIRET, VAT number) must appear in specific XML nodes depending on the client zone
The legal VAT mention determined in the previous step is embedded directly into the XML as a structured element, not just as visible text on the PDF

The output is a raw XML file, stored temporarily before the next phase.

Phase 2 — Injecting the XML and converting to PDF/A-3

The second component is a Python script using the factur-x library developed by Akretion — the same team behind the Factur-X standard itself.

This script does two things:

It takes the invoice PDF (generated by the PHP billing engine using mPDF) and the XML file produced in phase 1
It embeds the XML inside the PDF and converts the result to PDF/A-3b — the archiving format required by the standard

Why Python for this phase and not PHP? Because the factur-x library handles the PDF/A-3 conversion and XML embedding with precision that is difficult to replicate in PHP without heavy dependencies. The library also validates the XML structure against the EN16931 schema before injection — which acts as a built-in compliance check.

The final output is a single file: a PDF/A-3 with the XML embedded, fully compliant with Factur-X EN16931 Comfort profile.

The temporary file cycle

Between the two phases, temporary files are created and cleaned up automatically. The XML is written to a dedicated temporary directory, used during injection, then deleted once the final PDF is produced. Nothing persists beyond what is needed.

The result — what this architecture delivers

The output of this chain is a single invoice file that is both human-readable and machine-readable, compliant with Factur-X EN16931, ready for transmission to a Partner Dematerialization Platform (PDP) or direct exchange with a client.

A few things worth noting about what this approach delivers:

No SaaS dependency

The entire generation chain runs on the server where the billing system is deployed. No external API call is made during invoice generation. No data leaves the infrastructure. The invoice is produced, signed, archived and delivered entirely on-premise.

This matters for clients who cannot or do not want their financial data processed by a third-party cloud service.

No ERP required

The system does not sit on top of an ERP. It does not require an existing accounting software to function. The Factur-X output is produced directly from the billing data entered in the interface — client details, service lines, VAT zone, payment terms.

This makes it deployable for small and mid-size businesses that need compliance without the overhead of a full ERP migration.

Compliance is structural, not cosmetic

The VAT legal mentions are not added as text fields that a user can forget or mistype. They are determined by the system based on the client's country and VAT number, embedded in both the visible PDF and the structured XML. The correct mention always appears. The correct VAT rate is always applied.

This is the difference between a system that looks compliant and one that actually is.

Conclusion

Integrating Factur-X into an existing billing stack is not trivial, but it is achievable without rebuilding everything. The key is understanding what the standard actually requires — not just the file format, but the fiscal logic behind it.

The chain described here — PHP for XML construction, Python for PDF/A-3 conversion and injection — is stable, testable, and entirely self-hosted. It produces invoices that are compliant today and will remain compliant as the european e-invoicing mandate expands.

If you are working on a similar integration or have questions about the EN16931 structure, feel free to reach out.

Try it

A live demo is available — you can generate a real Factur-X EN16931 compliant invoice directly from your browser, no account required.
Try the Factur-X demo

https://palks-studio.com

Dependency as an Engineering Trade-Off

Palks Studio — Sun, 10 May 2026 14:49:48 +0000

Stability, control and long-term maintainability in backend systems

Dependencies are everywhere in modern software development.

Frameworks, libraries, external services, and specialized tools help accelerate development and avoid reinventing existing solutions.

In many situations, this is a reasonable choice.

A dependency can reduce development time, provide proven functionality, and simplify complex implementations.

However, every dependency also introduces a trade-off that is often invisible at first: part of the system’s behavior is no longer fully controlled by the people building it.

Solving problems today, creating complexity tomorrow

Adding a dependency usually solves an immediate problem.

A feature is implemented faster, with less effort, and the system moves forward quickly.

Over time, however, dependencies evolve:

breaking changes between versions
behavioral changes
reduced maintenance or abandonment
new technical constraints

The system may continue to function, but its stability increasingly depends on external factors.

Complexity rarely appears immediately.

It accumulates gradually as the system evolves.

When behavior escapes the system

The more layers a system relies on, the harder it becomes to explain why it behaves in a certain way.

An issue may originate from:

application code
an intermediate library
a version change
or an external service

A backend system may suddenly behave differently after what appears to be a minor update:

a dependency changes an internal behavior, an external API modifies a response format, or a framework update introduces a new constraint.

Nothing in the business logic was intentionally changed, yet the system itself no longer behaves the same way.

This diffusion of responsibility increases uncertainty.

Understanding a problem often requires understanding multiple systems at once.

At that point, the difficulty is no longer purely technical.

It becomes structural.

Reducing dependencies means reducing uncertainty

Reducing dependencies does not mean rejecting existing tools.

It means deciding what should truly belong to the system.

Some functionalities are central enough to justify a simple, controlled implementation. Others can remain external without significant impact.

The goal is not to minimize dependencies at all costs, but to limit those that directly influence core logic or critical system behavior.

The fewer external elements a system depends on, the more predictable its behavior becomes.

Stability as a consequence of control

The systems that are easiest to maintain are not necessarily those using the fewest tools.

They are often the ones where dependencies are clearly identified and limited to areas where they provide real value.

When the essential parts of a system remain under control, external changes become less risky.

Stability does not come from avoiding change, but from understanding what actually changes.

Balance rather than rejection

Dependencies are an integral part of modern development.

They allow teams to build faster and benefit from shared knowledge.

But every dependency shifts part of the control outside the system itself.

Understanding this trade-off leads to better decisions: accepting dependencies when they genuinely simplify the problem, and reducing them when they introduce more uncertainty than value.

Over time, these often invisible decisions determine whether a system remains understandable or gradually becomes difficult to evolve.

https://palks-studio.com

AI Agents Writing All Your Code: Comfort or Loss of Control?

Palks Studio — Fri, 24 Apr 2026 15:10:07 +0000

The new reflex: delegate everything

Over the past few months, we’ve seen the rise of AI agents capable of:

generating full codebases
modifying existing projects
automating complex tasks
making technical decisions

The reflex is simple:

“I’ll just let the AI handle it.”

And it works.

At least, on the surface.

The problem: we no longer know what we’re running

When an agent:

writes code
modifies files
restructures a project

who actually understands what’s going on?

In many cases:

the code is accepted without review
the logic is not fully understood
entire parts become opaque

We gain speed.

But we lose something fundamental:

understanding.

A system that works… until it breaks

It’s the same pattern we’ve seen before:

it works
we stack layers
we trust it
then one day… it breaks

And when it does:

no one knows where to look
no one understands the full logic
the system becomes hard to fix

The question no one is asking

Today, the focus is on performance, productivity, speed.

But very few people ask the real question:

what happens when we no longer control what we execute?

Because tomorrow, the issue might not be:

a bug
a mistake
a bad implementation

But something deeper:

total dependence on a system we don’t understand

What if we start hearing about compromised agents?

Today, it may sound exaggerated.

But we’ve already seen:

compromised dependencies
libraries injecting malicious code
popular tools becoming attack vectors

So the question is simple:

if an agent controls part of your code… what happens if it’s compromised?

And more importantly:

who is able to detect it?

The real issue isn’t AI

AI isn’t the problem.

It’s a powerful tool.

Useful.

Sometimes impressive.

The problem is how we use it.

Assistant vs pilot

There’s a huge difference between:

using AI as an assistant
letting AI take control

In one case:

you gain speed
you keep control

In the other:

you accelerate
but you lose understanding

Taking back control

Using AI agents isn’t a bad thing.

But a few simple principles make all the difference:

understand what is generated
limit automated layers
avoid delegating critical parts
keep logic simple and readable

Conclusion

Technology is moving fast. Very fast.

And AI agents will take more and more space.

But as automation increases,

control can decrease.

And in technical systems,

speed is not what makes them reliable.

Understanding is.

https://palks-studio.com

Stop letting your editor decide how your code should look

Palks Studio — Tue, 21 Apr 2026 16:37:41 +0000

Most developers don’t control their environment

Most developers don’t configure their environment.

They install extensions.

They stack tools.

They let everything run automatically.

And over time, they lose control.

The problem is not formatting

It’s uncontrolled automation.

format on save
hidden transformations
conflicting extensions
inconsistent results between machines

What starts as “productivity” becomes:

→ unpredictable diffs

→ broken formatting

→ code that changes without you asking

The real issue: loss of control

When your editor modifies your code automatically, you are no longer in control of:

when changes happen
what changes are applied
how your code is structured

That’s not tooling.

That’s delegation.

I built a different approach

Instead of automating everything blindly, I built a VS Code environment based on one idea:

Nothing happens unless you decide it.

No format on save.

No hidden actions.

No external dependencies.

Only explicit, controlled operations.

What this environment does differently

No automatic formatting
No “magic” behavior
No dependency on extensions

Everything is:

manual
predictable
reproducible

Controlled formatting, not automation

Formatting and cleanup are still there.

But they are:

triggered manually via tasks
applied only when needed
executed locally with Python scripts

You decide:

when to clean
what to modify
how far it goes

Local scripts, full control

Instead of relying on extensions:

clean.py → removes useless spaces, fixes structure
convert.py → normalizes line endings
space.py → detects issues without modifying
backup.py → creates timestamped local backups

Everything runs locally.

No network. No hidden logic. No surprises. :contentReference[oaicite:0]{index=0}

Three execution modes

You can run actions:

on the whole project
on the active file
on a custom selection

This avoids accidental global changes.

And keeps your code stable. :contentReference[oaicite:1]{index=1}

Why this matters

Because code is not just written.

It is maintained.

And maintenance requires:

consistency
predictability
control

Blind automation breaks all three.

This is not about tools

It’s about responsibility.

If your environment modifies your code without you noticing:

You are no longer responsible for your code.

Your tools are.

Who this is for

developers tired of fighting their editor
teams needing consistent formatting
anyone who wants a stable, predictable workflow

Final thought

Faster doesn’t mean better.

Automated doesn’t mean controlled.

And in the long run:

the code you control will always outlive the tools you depend on.

If you're interested in how it works under the hood:

Here’s a technical breakdown of the system architecture.

VS Code – Environment Pack

A configured working environment for Visual Studio Code.

This pack provides a clear and consistent framework for formatting, cleanup, and normalization

of common file types (.py, .html, .css, .js, .json, .txt),

using VS Code settings and locally executed Python scripts.

The goal is not blind automation,

but a controlled set of tools

that lets you keep full control over code structure, readability, and consistency,

regardless of the operating system.

Why this environment exists

Most editors automatically reformat code when saving files.

While convenient, this can introduce unexpected changes,

inconsistent formatting, or conflicts between extensions.

This pack takes the opposite approach:

no automatic formatting
no hidden actions
manual tools executed only when needed

The goal is to keep code stable, readable and predictable,

while giving full control to the developer.

Pack Structure

vscode_environment_pack_v1.1/
│
├── .vscode/
│   ├── settings.json           → Complete editor configuration (indentation, encoding, readability)
│   ├── keybindings.json        → Custom keyboard shortcuts (navigation, editing)
│   ├── tasks.json              → VS Code tasks for manual tool execution
│   ├── launch.json             → Script execution within the environment
│   └── extensions.json         → Local extension management
│
├── scripts/
│   ├── cleaning.py             → File cleaning and normalization
│   ├── conversion.py           → Format and encoding handling
│   ├── analysis.py             → File analysis (read-only)
│   └── backup.py               → Local file backup system
│ 
├── LICENSE.md                  → Terms of use and legal framework
│ 
└── docs/
    ├── TECHNICAL_README.md     → Technical documentation and internal structure
    ├── README_COMMERCIAL.md    → Project overview and public presentation
    ├── INSTALL.md              → Installation and usage guide
    │
    └── examples/
        ├── before.py           → Dirty / unstructured example files
        ├── after.py            → Clean, formatted versions generated by the pack
        ├── convert_lf.mp4      → CRLF files automatically converted to LF
        ├── indent_clean.mp4    → Broken indentation/margins fixed instantly
        ├── indent_python.mp4   → Badly indented Python file auto-corrected
        ├── backup.mp4          → Demonstrates automatic file backup on each save (Ctrl + S)
        │                         and how to restore a deleted file from the backup folder
        └── space_clean.mp4     → Broken file analyzed and margins detected (read-only)

If you want to explore the technical implementation, you can find it here:

https://github.com/Palks-Studio/vs-code-environment-pack

https://palks-studio.com

Static websites don’t limit features. They redefine where complexity lives

Palks Studio — Fri, 17 Apr 2026 15:10:23 +0000

Static Websites Are Not Limited Websites

Static websites are often associated with simple projects: landing pages, fixed content, or minimal websites without advanced functionality.

This perception largely comes from earlier stages of the web, where “static” meant limited interaction and little or no logic.

Today, that association no longer reflects reality.

A static website does not define what a project can do, but how it is structured.

Static does not mean minimal

A static website can integrate many modern features:

secure download systems
payments handled through external services
interactive interfaces
local chatbots
client-side animations and dynamic behavior

The difference is not in visible capabilities, but in where complexity is placed.

Instead of concentrating logic in a permanent server or database, functionality is isolated into specific components only where it is needed.

Moving complexity instead of spreading it

In many projects, a full backend is introduced by default, even when actual needs remain limited.

This often increases complexity:

continuous server maintenance
additional dependencies
larger error surface
constant updates

A static approach keeps the website itself simple while delegating only necessary parts to specialized services or scripts.

Complexity is not removed.

It is moved to controlled areas.

Performance and structural clarity

Static websites also provide structural advantages.

Content is directly accessible, structure remains readable, and behavior stays predictable. The absence of server-side generation on each request reduces potential failure points and simplifies hosting.

This structural simplicity makes long-term maintenance and project handover easier.

The project remains understandable without requiring complex infrastructure.

Most real-world needs

In practice, many web projects do not require a fully dynamic system.

Presentation websites, documentation, digital products, educational content, or information platforms can operate efficiently on a well-designed static foundation.

Advanced functionality can be added selectively without turning the entire project into a complex application.

An engineering choice

Choosing a static architecture is not about limiting a project.

It is often about defining a clear scope, reducing maintenance, and achieving more predictable behavior.

Static websites do not replace dynamic applications where they are necessary.

But in many cases, they provide a more stable result with less complexity.

This is not a step backward.

It is a structural decision.

At Palks Studio, websites are built as static, dependency-free systems. Bases are available here: https://palks-studio.com/en/static-site

If you're interested in how it works under the hood:

Here’s a technical breakdown of the system architecture.

Palks Studio — Static site + digital storefront

This repository contains the public website of Palks Studio, which combines:

a clean, tracking-free static HTML website
a lightweight server-side digital storefront
an autonomous PDF invoicing system
and secure token-based delivery of downloadable files

The system operates without a CMS, without a database, and without unnecessary SaaS dependencies,

relying solely on flat files (JSON/CSV) and minimalist PHP scripts.

The repository includes:

the public website (pages, styles, images, content)
payment and digital delivery components
as well as publicly accessible documentation with the aim of clarity, readability, and transparency

This repository is not a turnkey product, a framework, or a software library.

It serves as a reference artifact to understand the approach,

tools, and technical choices carried by Palks Studio.

About Palks Studio

Palks Studio designs technical tools, documentation structures,

and working environments intended to be:

readable
understandable
autonomous
maintainable over time

The emphasis is placed on:

functional simplicity
control of dependencies
transparency of technical choices
durability rather than trends

Project structure

/palks-studio-website/
│
├── fr/                                       → Pages du site (FR)
├── en/                                       → Pages du site (EN)
│
├── assets/
│   ├── css/
│   │   └── style.css                         → Global stylesheet (FR) / Feuille de styles globale (EN)
│   └── img/                                  → Images et visuels (FR) / Images and visuals (EN)
│
├── robots.txt                                → Règles pour moteurs de recherche (FR) / Search engine directives (EN)
├── sitemap.xml                               → Plan du site pour indexation (FR) / Sitemap for indexing (EN)
│
├── LICENCE.md                                → Conditions d’utilisation et cadre légal (FR)
├── LICENSE.md                                → Terms of use and legal Framework (EN)
│
├── core/                                     → Backend génération PDF (FR) / PDF generation backend (EN)
├── endpoint/                                 → Moteur de traitement du formulaire CSV (FR) / CSV upload form processing engine (EN)
│
├── storage/
│   └── protected/                            → Stockage sécurisé interne (FR) / Secure internal storage (EN)
│
├── config/
│   └── download/                             → Configuration interne des téléchargements (FR) / Internal download configuration (EN)
│
├── library/
│   ├── contracts/                            → Génération et templates de contrats (FR) / Contract generation and templates (EN)
│   ├── batch/                                → Interface d’import et traitement CSV (FR) / CSV import and processing interface (EN)
│   ├── payments/                             → Pages de gestion des paiements (FR) / Payment handling pages (EN)
│   ├── counters/                             → Gestion de la numérotation (FR) / Numbering management (EN)
│   ├── core/                                 → Fonctions internes (génération, email, PDF) (FR) / Internal functions (generation, email, PDF) (EN)
│   └── templates/                            → Modèles de documents (FR) / Document templates (EN)
│
├── docs/
│   ├── VUE_D_ENSEMBLE.md                     → Vue d’ensemble du système (FR)
│   ├── OVERVIEW.md                           → System Overview (EN)
│   ├── PROJECT-OVERVIEW_FR.md                → Vue d’ensemble du projet (FR)
│   ├── PROJECT-OVERVIEW.md                   → Project Overview (EN)
│   ├── README_FR.md                          → Présentation générale (FR)
│   └── README.md                             → General Overview (EN)
│
├── store/                                    → Fichiers produits numériques (FR) / Digital product files (EN)
│
└── endpoint/
    ├── endpoint_a.php                        → Initialisation d’une session de paiement (FR) / Checkout session initialization (EN)
    ├── endpoint_b.php                        → Traitement des événements de paiement (FR) / Payment event handler (EN)
    ├── endpoint_c.php                        → Traitement post-paiement (FR) / Post-payment fulfillment handler (EN)
    └── endpoint_d.php                        → Point d’accès sécurisé aux fichiers (FR) / Secure file access endpoint (EN)

If you want to explore the technical implementation, you can find it here:

https://github.com/Palks-Studio/palks-studio-website

https://palks-studio.com

Not All Complexity Is Bad — But Most of It Is

Palks Studio — Sat, 11 Apr 2026 17:12:47 +0000

Why complexity isn’t always the problem

Complexity is often seen as something to eliminate.

But not all complexity is bad.

Some of it is necessary.

Some of it shouldn’t exist.

The confusion

Most systems don’t fail because they are complex.

They fail because the wrong complexity accumulates.

The real issue

Over time, systems mix two things:

what is required
what just happened to be added

And the difference disappears.

What actually matters

Good systems don’t avoid complexity.

They make it visible and intentional.

A better way to think about it

Instead of asking:

“how do we simplify?”

Ask:

“which complexity belongs here?”

Full article → https://palks-studio.com/en/useful-vs-accidental-complexity

https://palks-studio.com

Factur-X EN16931: your invoice is probably not compliant (and you don't know it)

Palks Studio — Fri, 03 Apr 2026 17:03:31 +0000

Most invoicing solutions claim Factur-X compliance.
Few actually pass all three validation levels.

The three levels

Factur-X conformity requires passing all of these:

XSD validation — XML structure is syntactically correct
Schematron validation — EN16931 business rules are respected
PDF/A-3 validation — the PDF document is archivable with the XML correctly embedded

Where most solutions fail

PDF/A-3 is the real problem.

Common PHP PDF libraries — Dompdf, TCPDF — produce DeviceRGB without ICC OutputIntent.
The XML can be perfectly structured. The invoice is still rejected.

The combination that works

mPDF generates clean PDF/A-1b output
factur-x (Python) injects the EN16931 XML and converts to PDF/A-3

Result: XSD ✅ Schematron ✅ PDF/A-3 ✅

Full note → https://palks-studio.com/en/electronic-invoicing-compliance

https://palks-studio.com

Why real-time can unnecessarily complicate simple systems

Palks Studio — Wed, 25 Mar 2026 15:55:42 +0000

Real-time architectures are everywhere.

But not every system needs to be instant.

In many cases, real-time introduces more complexity than value.

The problem

Most systems today assume everything must update instantly.

But many business processes don’t need that.

The hidden cost

Real-time systems create multiple intermediate states.

Over time, this makes systems harder to understand and maintain.

A simpler approach

Some systems benefit from clear, step-based processing instead:

data preparation
validation
processing
output

Full article → https://palks-studio.com/en/real-time-unnecessary-complexity

https://palks-studio.com

Stop stacking tools. Build systems that run on their own.

Palks Studio — Sun, 22 Mar 2026 17:14:05 +0000

Entrepreneurs, freelancers, agencies,

A complete autonomous system running on your own hosting, without SaaS, subscriptions or external dependencies.

Are you still stacking tools to run your business?

Zapier.
Make.
Plugins.
Subscriptions.
Updates.
Dependencies.

It works…

until it breaks.

At Palks Studio, we do the opposite.

We remove dependencies.

We deploy systems directly on your infrastructure.

No SaaS.
No subscriptions.
No surprises.
No updates breaking everything.

Internal scripts.

Autonomous tools.

Systems that run on your own hosting.

For example:

quotes → signature → invoicing → payment → revenue tracking
https://palks-studio.com/en/invoicing-without-saas

CSV → batch processing → structured outputs → automated delivery
https://palks-studio.com/en/batch-invoicing-facturx

Invoicing.
Automation.
Internal tools.

One goal:

make it work.
simply.
over time.

Less tools.
Less complexity.
More control.

If your system depends on 5 external services,

it’s not a system.

It’s a fragile chain.

There’s another way to build.

Simpler.
More stable.
Fully controlled.

https://github.com/Palks-Studio/palks-studio-website

https://palks-studio.com

If your business depends on 5 tools, you don’t have a system

Palks Studio — Mon, 16 Mar 2026 14:11:23 +0000

Still managing quotes, invoices and payments across multiple tools?

I built a complete financial system that runs on your own domain.

Not a SaaS.
No subscription.
No critical dependencies.

The system runs on your own hosting.

Quotes → online signature → invoicing → payment confirmation → revenue journal.

Everything is semi-automated.

Quote / contract

Simple interface:

your fixed company details
client information
service lines
currency / VAT
your fixed banking details

The PDF is generated directly in the browser and sent to the client by email.

No data is sent to the server before validation.

Once the quote is sent:

a secure link is sent to the client
the client can view and sign the quote online
the quote is archived
you receive a confirmation email

The quote then becomes a signed contract.

Invoicing

The system includes a smart client lookup.

You only need to enter a single piece of information:

email
SIRET / SIREN
client name

and the system automatically retrieves:

the client’s details
their existing quotes (a list is suggested in the quote field)

The most recent quote is automatically suggested.

You simply select the correct quote from the list.

The system retrieves:

service lines
amounts
client information

If no quote exists, the invoice can be generated directly with a free service description.

Once validated, the system immediately generates:

the invoice
the stamped invoice (pre-generated)

The invoice is sent to the client and archived.

The stamped version is stored while waiting for payment.

Payment confirmation

The interface lists all pending invoices.

One click is enough to:

mark the invoice as paid
send the stamped invoice
add the entry to the revenue journal

The system also allows:

monthly invoice export (ZIP)
monthly revenue export (CSV)
annual revenue journal export

All data is stored in simple files.

No database.

This system is designed to be:

autonomous
installable on any PHP hosting
bilingual FR / EN
fully documented

The data stays with the client.

https://palks-studio.com/en/invoicing-without-saas

This is the type of systems I design at Palks Studio:

simple tools that automate complete business processes.

If you want to install this system on your own infrastructure:

contact@palks-studio.com

If you're interested in how it works under the hood:

Here’s a technical breakdown of the system architecture.

Overview

Billing System is a suite of three interconnected billing tools accessible from a unified interface. It covers the full lifecycle of a service engagement: from quote generation to invoice settlement, including electronic signature and structured archiving.

The system is designed to be deployed directly on the client's server, on a standard Apache hosting environment with PHP 8.x and Composer. It requires no database, no third-party service, and no subscription.

Features

Client-side quote PDF generation (jsPDF)
Server-side invoice PDF generation (Dompdf)
Automatic pre-generation of the paid invoice at billing time
Electronic quote signing by the client (touch/mouse canvas)
Client auto-fill from archives (SIREN, SIRET, VAT, email, name)
Structured archiving by client and period
Secure sequential numbering (file lock)
Monthly export of invoices (ZIP)
Monthly export of revenue records (CSV)
Yearly export of the revenue journal (CSV)
Automatic email notifications at each stage (quote, invoice, settlement)
Cross-module navigation bar
Bilingual FR/EN interface with real-time language switch
Dark mode / light mode with persistence
No database
No SaaS dependency
Basic security: secure sessions, tokens, brute-force protection

Project Structure

billing-system/
│
├── public/
│   │  └── assets/
│   │      ├── logo*              → Company logo if provided
│   │      ├── signature.png      → User signature used on quotes and invoices (PNG format)
│   │      └── favicon*           → Optional favicon displayed in the browser tab
│   │
│   ├── Endpoint a                → Quote generation endpoint
│   ├── Endpoint b                → Invoice generation endpoint
│   ├── Endpoint c                → Direct invoice generation endpoint
│   ├── Endpoint d                → Paid invoice generation endpoint
│   │
│   ├── Interface a               → Quote generation interface
│   ├── Interface b               → Direct invoice generation interface
│   ├── Interface c               → Payment tracking interface
│   ├── sign.php                  → Signature interface
│   ├── export a                  → Archived invoices ZIP export
│   ├── export b                  → Revenue journal CSV export
│   │
│   ├── search.php                → Client search and auto-fill
│   ├── serve.php                 → Secure PDF access via token
│   └── save.php                  → Quote save and archiving
│
├── vendor/                       → Libraries used by the document generation engine
├── templates/                    → HTML templates used for document rendering
│
├── app.php                       → Central configuration for issuer and bank details
├── mailer.php                    → Internal email sending script with attachments
├── core.php                      → Main engine: generation logic, calculations and archiving
├── LICENSE.md                    → Project license
│
├── contracts/                    → Signed and unsigned quote archiving
├── counters/                     → Numbering counters (quotes and invoices)
├── logs/                         → System logs (optional)
├── data/                         → Operational data
│
└── docs/
    ├── USER_GUIDE.md             → User guide
    ├── OVERVIEW.md               → Project overview and general system description
    └── README.md                 → Installation and usage documentation (client version)

If you want to explore the technical implementation, you can find it here:

https://github.com/Palks-Studio/billing-system

https://palks-studio.com

You don’t need a backend to generate quotes

Palks Studio — Sun, 08 Mar 2026 19:29:21 +0000

Creating a quote should be simple.

Yet most tools require:

account creation
email registration
server-side storage
sometimes even a subscription.

I wanted to try a different approach.

A quote generator that runs entirely in the browser.

No backend.

No API.

No database.

You can test it here:

https://palks-studio.com/fr/generateur-devis

The tool generates a professional PDF quote directly in the browser without sending any data to a server.

Everything runs in the browser

Everything happens client-side.

User fills the form

↓

JavaScript processes the data

↓

PDF is generated locally

↓

Browser downloads the file

No network request is required.

The only external dependency is the jsPDF library.

Generating PDFs directly in JavaScript

The generator relies on jsPDF to build the document directly in JavaScript.

<script src="https://cdnjs.cloudflare.com/ajax/libs/jspdf/2.5.1/jspdf.umd.min.js"></script>

Once loaded, creating a PDF is straightforward.

const { jsPDF } = window.jspdf;

const doc = new jsPDF({
  unit: "mm",
  format: "a4"
});

From there, everything can be drawn directly into the document.

The form mirrors the final document

The form mirrors a real quote structure.

It contains:

issuer information
client information
quote metadata
service lines
totals
payment details

Example structure:

<div class="card">

  <div class="card-header">
    <div class="card-header-title">Your company</div>
  </div>

  <div class="card-body">
    <input name="issuer_name" required>
    <input name="issuer_email">
    <input name="issuer_phone">
  </div>

</div>

Each section of the form maps directly to a block inside the generated PDF.

Quotes need flexible line items

Quotes require flexible service lines.

Users can dynamically add or remove rows.

function addLine() {

  lineCount++;

  const row = document.createElement("div");
  row.className = "line-row";

  row.innerHTML = `
    <input name="lines[${lineCount}][desc]">
    <input name="lines[${lineCount}][qty]" type="number">
    <input name="lines[${lineCount}][price]" type="number">
  `;

  container.appendChild(row);

}

Each line contains:

description
quantity
unit price
VAT rate

Totals update instantly when values change.

All calculations happen instantly

All calculations are transparent and client-side.

function updateTotals() {

  let subtotal = 0;
  let vatTotal = 0;

  document.querySelectorAll(".line-row").forEach(row => {

    const qty   = parseFloat(row.querySelector('[name*="[qty]"]').value) || 0;
    const price = parseFloat(row.querySelector('[name*="[price]"]').value) || 0;
    const vat   = parseFloat(row.querySelector('[name*="[tva]"]').value) || 0;

    const lineHT = qty * price;

    subtotal += lineHT;
    vatTotal += lineHT * vat / 100;

  });

  const total = subtotal + vatTotal;

}

The UI immediately displays:

Subtotal
VAT
Total amount

before the PDF is generated.

Turning form data into a document

When the user confirms, the script builds the document.

const { jsPDF } = window.jspdf;

const doc = new jsPDF({
  unit: "mm",
  format: "a4"
});

Then the script draws the document:

header
issuer block
client block
service table
totals
notes
footer

Example:

doc.text("QUOTE", 18, 30);
doc.text(quoteNumber, 18, 38);

Every field comes directly from the form inputs.

Keeping the layout stable

PDF layout can break when text becomes longer than expected.

To prevent layout issues, the generator wraps text dynamically.

doc.splitTextToSize(text, maxWidth);

Each block calculates its own height before being drawn.

This prevents overlapping elements and keeps the layout stable.

Why a backend is unnecessary here

For this type of tool, a backend is often unnecessary.

Running everything in the browser provides several advantages.

Privacy.

No data is transmitted to any server.

Simplicity.

No authentication, no database, no API.

Lightweight hosting.

The entire generator is essentially a single HTML page.

It can run on:

static hosting
GitHub Pages
any simple web server

What this approach does not solve

This approach also has some limitations.

There is no:

quote history
client management
automated emailing
electronic signature workflow

But for generating quick quotes, it works extremely well.

What this tool is designed for

The goal was not to build a SaaS product.

The goal was to build a tool that is:

simple
frictionless
immediately usable

No login.

No tracking.

No data collection.

Just a form and a downloadable PDF.

Try it yourself

You can test it here:

https://palks-studio.com/en/quote-generator

It works on:

desktop
mobile
any modern browser

Sometimes simpler is better

Modern web tools often become unnecessarily complex.

For some use cases, a simple client-side application is more than enough.

A single HTML file with JavaScript can already provide:

a structured form
dynamic calculations
professional PDF generation

Sometimes simplicity is the best solution.

https://github.com/Palks-Studio/free-quote-generator

https://palks-studio.com

Generating Factur-X is easy. Making it valid is not.

Palks Studio — Wed, 04 Mar 2026 21:46:31 +0000

When I started working on B2B e-invoicing, I thought the technical part would be straightforward. Generate a PDF, embed an XML, follow a standard. On paper, it seemed linear.

In practice, it's something else entirely.

Here's what actually took time — not the concepts, but the details that break everything in production.

The Comfort profile is not declared — it is earned

EN16931 defines several profiles. The Comfort profile, the one that guarantees real interoperability with accounting systems, requires strict identifier completeness.

SIREN alone is not enough. SIRET alone is not enough. The combination of SIREN + SIRET + VAT number determines the profile declared in the XML. If one identifier is missing, the profile changes. And an incorrect profile means a technically invalid invoice — even if it looks perfectly fine visually.

I implemented conditional validation logic before generation. No silent correction, no approximation. Either the data is complete, or the invoice does not go out.

Multi-period invoicing is a state problem, not a calculation problem

Invoicing across multiple months in a single document seems simple. It is not.

The real issue: a period included in an issued invoice is permanently closed. It cannot be re-invoiced, partially modified, or cancelled. This is not a software constraint — it is a legal and accounting one.

I had to model an explicit state system per period and per client, using immutable archiving flags. No database — only locked, deterministic and traceable files.

Deduplication without a database

The classic question: how do you prevent issuing the same invoice twice if the process is restarted?

My answer: file-based locks. Each execution cycle checks for the existence of a lock file before generating anything. No race condition, no distributed transaction, no external dependency. One execution = one deterministic cycle. If the file exists, skip. Otherwise, generate and lock.

Simple, traceable, reliable.

The pipeline runs on cron — no background process, no service to keep alive

No persistent process running in the background, no service to maintain active, no SaaS dependency. The engine triggers, processes, archives and stops. Each execution is independent and reproducible.

This architectural choice has a direct consequence: if something goes wrong, there is nothing to restart, nothing to debug live. Logs are exhaustive, states are explicit, generated files are evidence.

What I take from this

Factur-X is not a PDF generation problem. It is a structured pipeline problem — controlled states and normalized data before production.
Tools that "generate Factur-X" are plentiful. Systems that guarantee end-to-end compliance, full traceability and zero implicit correction are far less common.

https://palks-studio.com/en/batch-invoicing-facturx

If you're interested in how it works under the hood:

Here’s a technical breakdown of the system architecture.

Overview Project

This repository presents a financial automation system designed to handle:

invoice generation (single & batch)
revenue tracking
payment reconciliation
client balances
accounting-ready exports

The system is deterministic, auditable, and explicit by design.

It operates:

without a database
without a CMS
without a SaaS dependency
without any exposed web interface

All executions run server-side, via CLI scripts and cron, with a strict separation of responsibilities.

This project is not a product, not a SaaS, and not a plug-and-play tool.

It documents a production-grade approach to financial automation.

Over time, the engine has been progressively extended

to cover real-world business cases,

without compromising its original design principles.

The billing system now supports:

multi-line invoices
multiple VAT rates per invoice
complex or extended service periods
multi-month billing scenarios
complex combinations while remaining EN16931 Comfort compliant

This functional expansion did not alter

the deterministic, auditable, and traceable nature of the system.

Electronic invoicing (Factur-X)

The system natively integrates Factur-X electronic invoicing (hybrid PDF with embedded XML),

in compliance with the European EN 16931 standard (Comfort profile):

generation of a semantically EN 16931-compliant Factur-X XML
XML validation (XSD and Schematron)
injection of the XML into the PDF
production of a single final document: the Factur-X hybrid PDF
direct integration into the run.php and run_batch.php pipelines
no parallel formats
no persistent XML storage

The system targets business compliance and e-invoicing interoperability (France / EU).

PDF/A compliance (document archiving) is not a functional objective of the project and is deliberately out of scope.

Factur-X is handled as a native component of the engine,

not as an external or optional module.

Project structure

automation_finance/
│
├── engine/                           → Core automation engine (billing, generation, processing)
├── data/                             → Internal data storage (clients, invoices, tracking)
├── tools/                            → Internal utilities and maintenance scripts
├── exports/                          → Data export and reporting
├── downloads/                        → Generated document delivery
├── clients/                          → Client configuration
├── contracts/                        → Legal and contractual documents
│
├── LICENCE.md                        → Conditions d’utilisation et cadre légal (FR)
├── LICENSE.md                        → Terms of use and legal Framework
│
├── LICENCE.md                        → Conditions d’utilisation et cadre légal (FR)
├── LICENSE.md                        → Terms of use and legal Framework
│
└── docs/
    ├── README_FR.md                  → Documentation générale du système (FR)
    ├── README.md                     → General system documentation
    │
    ├── SERVICE_MEMO_FR.md            → Note interne de positionnement du service (FR)
    ├── SERVICE_MEMO.md               → Internal Service Positioning Memo
    │
    ├── README_DEPLOY_FR.md           → Guide d’installation et d’exploitation (FR)
    ├── README_DEPLOY_EN.md           → Installation and Production Guide
    │
    ├── VUE_DENSEMBLE_AUTOMATION.md   → Vue d’ensemble du système d’automatisation de facturation (FR)
    └── SYSTEM_OVERVIEW_AUTOMATION.md → Billing Automation System Overview

If you want to explore the technical implementation, you can find it here:

https://github.com/Palks-Studio/automation-finance

https://palks-studio.com