How to Invoice as a Freelancer in France for Auto-Entrepreneur TVA Compliance

If you need a safe default, treat France invoicing as a controlled workflow, not a template exercise#

Before you start#

If you need a safe default, treat France invoicing as a controlled workflow, not a template exercise. Confirm seller status, classify the client, lock the invoice schema, flag TVA treatment before issue, and keep the evidence pack with the delivered document. That is the practical frame for the rest of this guide.

Step 1. Treat France invoicing as a controls problem, not a template problem. The baseline rules are straightforward. A freelance invoice is the business document that records the sale of products or services, and invoicing is required for transactions between professionals. The real risk shows up when your platform has to apply that baseline repeatedly across different client flows, different seller profiles, and unclear TVA treatment, without leaving room for guesswork.

Step 2. Anchor scope in the right seller regime. In France, the micro-entreprise, formerly called auto-entreprise, is a simplified regime for individual entrepreneurs. Simplified does not mean informal. Public guidance still presents it as a status with core accounting duties, and one of the first duties commonly highlighted for a micro-entrepreneur is keeping a revenue book that records income details for the year.

That matters because the invoice should not stand alone. If your payout record, invoice record, and income register logic do not tie together, you create review problems later, even when a single invoice looks fine on its face.

Step 3. Decide up front what you will validate and what you will store. This guide is not trying to cover every detail of drafting a French invoice. The practical goal is narrower. Make a few control decisions explicit: what should be checked on every invoice, what evidence should be retained with it, and which questions should be escalated instead of solved with custom wording in a template.

Use a simple checkpoint here. For every control you adopt, save the source page, URL, and access date used to support it. If you later need to explain why a reviewer approved or rejected a document, that snapshot is often more useful than the invoice PDF itself.

Step 4. Assume public summaries can change faster than your internal rules. That is one reason edge cases get expensive. In the materials behind this guide, one accounting explainer shows a publication date of 11/10/2024 and an update date of 28/03/2025. Stripe's France invoicing content also points readers to requirement changes since 2024 and to a section on what will change in 2026.

In practice, build periodic verification into your process. When a rule summary changes, review the affected controls, record the effective date internally, and avoid forcing new logic onto older invoices without a clear basis.

Step 5. Escalate TVA and legal ambiguity early. The common failure mode is not a missing file. It is operational drift. Teams reuse old invoice language, treat all customers the same, or assume a public explainer fully resolves a micro-entrepreneur edge case when it does not. If TVA treatment or seller-status interpretation is unclear, stop and route it to a named owner rather than improvising. That is the posture the rest of this guide builds on.

If you want a deeper dive, read A French Micro-Entrepreneur's Guide to Invoicing a US Client.

Set scope before you design controls#

Define the seller group in scope#

Set scope first: if you cannot name the seller profile, you cannot run reliable invoice controls. In this context, start with auto-entrepreneur and micro-entrepreneur profiles, then include only sole-proprietorship variants your team has already mapped to the same review path. A practical control is a required onboarding tag such as auto-entrepreneur, micro-entrepreneur, same-rules sole proprietorship, or out of scope.

Keep activity type explicit as well. The referenced micro-entreprise framing covers commercial, craft, or liberal activity, with annual caps of €188,700 (commercial) and €77,700 (artisanal or liberal). Use that to confirm regime fit, not to infer TVA treatment.

Separate your source sets#

Separate source sets before you write rules. Keep one register for general invoice guidance and one for micro-entrepreneur-specific guidance, then record which source supports each control your team applies. This keeps reviewer decisions traceable without assuming one source always overrides another.

Checkpoint: every control should have a source URL, access date, and saved copy. If a candidate source is unavailable or empty, do not let it drive production logic.

Name the escalation owner#

Set escalation ownership now so edge cases do not turn into ad hoc invoice wording. Route interpretation questions to a compliance lead, and send unresolved TVA or VAT-exemption mention cases to tax or legal counsel. If a seller states TVA is not due up to a turnover limit but your team cannot validate the required mention, pause issuance and escalate.

For a step-by-step walkthrough, see Improving Credit Card Reconciliation for Platforms with Auto-Match Invoice Controls.

Prepare the minimum evidence pack before first invoice#

Build a small, defensible evidence pack before first issuance: core identifiers, conditional profile artifacts, and the exact source snapshot your reviewer used.

Collect core identifiers#

For first-invoice validation, the strongest supported control is the SIRET check. In this source set, SIRET is presented as a mandatory invoice identifier and as a 14-digit number.

Use a strict first checkpoint:

• SIRET is present in onboarding
• SIRET is exactly 14 digits
• the same SIRET appears on the first invoice
• SIREN and RM/RCS fields are either captured or explicitly marked not collected for that seller profile

Keep RM/RCS handling conditional. This source set supports collecting them where relevant, but not treating them as universal invoice fields for every auto-entrepreneur.

Define conditional profile artifacts#

Keep non-core documents in a conditional lane, not your universal invoice checklist. For example, include a slot for assurance responsabilite civile professionnelle, but require it only when the seller's activity, contract terms, or internal risk policy triggers that check.

This avoids false rejects. If a category triggers the insurance control, hold invoice issuance until the document is attached or an exception owner signs off.

Freeze the legal-reference snapshot#

Store the exact onboarding basis, not just a URL. Keep the source URL, access date, and saved page version, plus the internal policy note that maps that source into your control rule.

Your audit test is reproducibility: another reviewer should be able to reopen the file later and see the same rule basis and the same identifiers used to approve first issuance.

Related: How to Get a SIREN/SIRET Number as a Freelancer in France.

Route each transaction to invoice or recu with a client-type decision table#

Route by client type first, then choose the document type. For this section's source pack, the legal triggers in France for when to issue a recu instead of an invoice are not established, so treat that path as policy-controlled, not assumed.

Set one explicit branch: confirmed B2B can follow your invoice path, while B2C should use a recu path only when you already have an approved France-specific basis on file. If classification is unclear, block issuance and escalate before payment confirmation.

Make the route explainable in your tooling. Log client type, chosen document type, evidence used, reviewer or queue, decision timestamp, and escalation reason when applicable, so audits can reconstruct why the document path was chosen.

Related reading: How Non-Resident Freelancers Should Handle TVA in France.

Build the invoice field checklist your system enforces#

Your safest default is a locked invoice schema, not flexible free text. In France flows, that is what prevents missing mandatory mentions, broken numbering continuity, and unclear TVA treatment.

Define one locked core schema#

Make these fields non-optional in your baseline schema: seller identity, buyer identity, unique invoice number, issuance date, sale or service date, billing address for seller and buyer, and line-item detail with precise designation plus unit price excluding VAT.

Use these legal anchors in your control logic:

• Article 242 nonies A (annexe II au CGI) for numbering, issuance date, and VAT-related mentions.
• Article L441-9 du Code de commerce for sale/service date, billing addresses, and line-item detail.

For numbering, enforce a chronological, continuous sequence set by the supplier.

Validate French identifiers from seller profile data#

Do not rely on manual entry for identifiers. Pull identity fields from the seller profile and block issuance when required profile-backed data is missing for the case in scope.

Service-Public guidance for entrepreneurs individuels includes identity details such as address and SIREN. Support the mention "Siret en cours d'attribution" where applicable, and require RCS followed by the city of the registry clerk's office when the seller status makes RCS relevant. Keep RM as a review flag unless your approved rule set establishes it as mandatory for that seller type.

Make TVA logic conditional and keep overrides traceable#

Treat TVA as conditional fields, not optional notes:

• If TVA applies, require the applicable VAT rate.
• If franchise exemption applies, require "TVA non applicable, art. 293 B du CGI".

When a case uses an exception path, require an attached rule reference in the case record so a reviewer can trace why the document passed. That attachment is an internal control, not a statutory invoice field.

You might also find this useful: How to Invoice as a Freelancer Without Chasing Late Payments.

Apply TVA logic with explicit decision rules#

Lock TVA treatment before issue: if TVA applies, require VAT fields; if it does not, require the approved exemption mention and reviewer signoff; if treatment is unclear, block issuance and escalate.

Encode a hard TVA branch#

Use three states only: TVA applicable, VAT exemption approved, or unresolved. EU-level guidance supports a default expectation that established businesses register and charge VAT, while France-focused secondary guidance indicates some micro-entrepreneurs may not handle VAT up to certain turnover conditions. That is enough to require controlled branching, not free-text judgment at draft time.

Use the table above as the hard branch. Then run a branch-consistency check: compare visible tax fields on recent invoices to stored seller status, and flag contradictions for review.

Escalate ambiguity instead of drafting around it#

Treat unclear TVA handling as an escalation event, not a wording choice. Route cases to the named France tax or legal owner when seller status changes, a transaction type is new, or buyer context makes treatment uncertain.

Define and publish a response SLA, and require a written decision with treatment, rationale, and effective date. Store that decision with the seller profile snapshot and draft invoice so the case is defensible later.

Version TVA logic by effective date#

Keep a TVA change log tied to France guidance reviews: what changed, who approved it, when it takes effect, and which invoice issue dates it governs. Do not overwrite prior logic without preserving historical applicability.

Add a periodic control to test historical invoices against the rule version active on their issue date. This helps explain why older invoices may differ from current TVA handling.

This pairs well with our guide on How Global Inflation Changes Freelancer Rates and Real Earnings.

Control sequencing from issuance through retention#

Once TVA treatment is fixed, lock the invoice lifecycle in order: create, validate mandatory mentions, deliver, confirm payment status, then archive the delivered record with references that cannot be silently swapped.

Build a no-skip issuance sequence#

Do not let payment confirmation happen before validation, and do not archive from a draft. For each invoice, keep a visible status trail: created, validated, delivered, payment state updated, archived. That gives finance, compliance, and ops one consistent timeline.

Sample recent invoices and confirm the delivered PDF matches the stored status history. A common break is post-delivery edits followed by a re-exported PDF, which leaves the archive out of sync with what the client received. Treat the archived version as the delivered version, not the latest editable draft.

Enforce continuous numbering and duplicate checks#

Require one numbering-series rule per seller profile, then run regular exception checks for duplicate numbers, skipped numbers, reused numbers after cancellation, and issue dates that do not line up with sequence.

Verification is straightforward: sort by seller, then by issue date and invoice number, and investigate every break. Red flags include two PDFs with the same number, one invoice number tied to different payout records, or a corrected invoice that reuses the original number without a linked correction record. In high-volume flows, duplicate detection should be automated.

Archive the same transaction story every team will reconcile#

Retention controls only work if the archive aligns with the ledger and payout trail. Archive the invoice with the transaction references your teams use, because invoicing, collections, VAT, and treasury sit on the same operational chain, and administrative errors can create direct costs.

At minimum, keep these linked artifacts in one case file or record set. This is an internal control recommendation, not a statement of French legal retention law.

• final delivered invoice PDF
• seller profile snapshot used at issue time
• delivery evidence, such as send log or portal timestamp
• ledger entry ID or journal reference
• payout or settlement reference
• payment status history
• reviewer decision for exceptions, including VAT exemption mention approval where relevant

Preserve originals when invoices are rejected or corrected#

If an invoice is rejected or needs correction, preserve the original, issue a corrected document, and link both with a reason code and cross-reference. A reviewer should be able to see the full chain quickly: original number, rejection reason, corrected number, delivery timestamp, and final payment outcome.

The main failure mode is destructive editing. If the original PDF disappears, ledger entries, payout records, and client correspondence stop reconciling to one document history.

We covered this in detail in How Freelancer Marketplaces Handle W-8/W-9 Migration Decisions.

Avoid overbuilding tooling in the first release#

Start with the smallest tooling setup that removes legal ambiguity and preserves a defensible record, then add automation only after those controls are reliable. In phase one, tool depth matters less than whether you can prove what was issued, how exceptions were handled, and what was actually delivered.

Prioritize auditability over feature volume#

Use the first release to enforce clear validation and traceable outcomes. A simple check is to sample recent invoices and confirm you can see the issued document, validation result, delivery record, and exception decision in one place.

More features are not automatically lower risk. A basic setup with strong traceability is usually safer than deeper automation you cannot audit cleanly.

Prefer configurable validation and exception workflows#

Before building custom logic, use configurable required fields, approval gates, and rejection reasons. Keep the release focused on controls your ops team can run consistently without engineering intervention.

This is also consistent with the EU-level context: the Commission's evaluation on Directive 2014/55/EU (SWD(2024) 39 final, 19.2.2024) flags interoperability and uptake challenges, even as B2G mandates expanded across 17 Member States and policy discussion includes a common approach across B2G, B2B, and B2C.

Keep a manual review queue until controls are dependable#

If your tool cannot reliably enforce your mandatory schema for auto-entrepreneur cases, route those invoices to manual review with a reason code and reviewer decision. Do not automate around unresolved control gaps.

For the full breakdown, read How Much Should a Freelancer Save for Taxes? A Monthly Reserve Rule and Quarterly True-Ups.

Conclusion#

The practical win in France is not a longer tutorial for finance or support. It is a tighter control sequence that forces explicit decisions on document type and retained evidence before anything is issued.

Step 1. Confirm seller scope and governing sources. Start by deciding who your process actually covers. Then pin the source reference used for each rule, because general guidance is not the same thing as a complete rule set for every case. Your verification point is simple: a reviewer should be able to open the seller record and see both status and the source snapshot used to justify the controls.

Step 2. Route B2B and B2C transactions before drafting anything. For the France-specific branch in the cited guide, professional-to-professional work requires an invoice. Work with individuals is generally treated differently, with exceptions explicitly listed for distance sales and certain deliveries at public auctions. When no invoice is issued, some services still require a reçu, including services at or above 25€ including tax, and property work is listed among those cases. One useful checkpoint is whether your tool logs the client classification and selected document path.

Step 3. Enforce the document schema instead of relying on memory. Your document rules should be validated in the product, not added as free text at the end. That means required fields and identifiers are captured as required fields or controlled options, including RM or RCS mentions where relevant.

For a reçu, the cited source is more specific than many teams expect: names and addresses of both parties, the date and place the service was delivered, duplicate issuance, and the original handed to the customer no later than payment of the balance. The same source also says reçu delivery is optional if a detailed estimate was issued and accepted by the customer.

Step 4. Escalate ambiguity instead of drafting through it. If the client classification is unclear, or the required document path cannot be defended from the source set you maintain, stop and escalate. The evidence pack should include the draft document, seller status, transaction facts, reviewer note, and the exact pages consulted. That manual step slows issuance, but it is much cheaper than defending a valid-looking document with broken logic later.

Step 5. Tie issuance, corrections, and retention together. Do not stop at sending the document. Preserve issued records, keep correction history, and retain the evidence needed to trace each transaction end to end.

Use this launch checklist, and then confirm what is supported for your specific country or program with Talk to Gruv:

• Confirm in-scope seller types and governing source references.
• Implement B2B/B2C routing to invoice or reçu with logged outcomes.
• Enforce mandatory schema and reçu conditions in validation, not notes.
• Define escalation rules for ambiguous classification or document path.
• Verify reçu issuance timing (duplicate + original), correction links, and retention records.