Electronic-invoicing implementation cost: build your budget

The quote separates five headings: subscription, integration, data, acceptance and operations. We recommend stating assumptions and ownership for each before comparing amounts.

Budget increases with source count, entities and exceptions. A feature included in the subscription does not eliminate data preparation or testing. We request written confirmation of covered functions, volume limits and additional services.

Operating costs should be tracked separately from implementation costs. We recommend counting rejections, correction time and recurring incidents. Indicators also include posting delay and receipt disputes.

Days sales outstanding (DSO) depends on payment terms, sales and collections activity. We compare consistent periods and volumes before linking a change to the new process. Measurement aims to identify tasks and exceptions consuming time.

A reliable range requires source, entity, volume and data-quality information. We request the invoicing-system list, roles and interfaces. Invoice count matters, but process and exception count also explain workload. A low volume from several poorly connected sources can still require substantial work.

We separate issued invoices, received purchases, B2C sales and international activity. VAT regime and payment data can add controls. Each company retains its scope even where the group shares a tool. Estimates describe assumptions: covered sources, available data, testing and training. Changed assumptions lead to a revised estimate.

The deadline separates receipt and issuing. Since 1 September 2026, receipt concerns VAT-taxable businesses within the French scope. SMEs and micro-enterprises prepare issuing and e-reporting for 1 September 2027. We recommend budgeting phases separately when implemented at different times, while retaining their shared dependencies.

Incomplete data increases preparation work and post-launch corrections. We list duplicates, missing identifiers and inconsistent addresses in the source system. An approved platform does not automatically repair neglected master data. Correcting only in the platform can mean repeating the work after the next import.

Budgeting distinguishes one-off cleansing from durable maintenance rules. Who creates a record? Who approves changes? How does data reach other tools? We recommend allocating time to these answers and their tests. Master-data quality must remain monitored after the project, particularly when sales or entities change.

The trade-off remains conditional: if the company already has a PA integrated with accounting, we prioritise data quality before another tool purchase. If the source cannot produce the required structured format, integration or replacement becomes the priority. Diagnosis identifies this dependency before comparing subscriptions.

A connector budget includes data mapping, responses and maintenance. We ask what is native, what requires development and who maintains the integration. Quotes specify systems, entities and formats: Factur-X, UBL or CII according to confirmed capabilities. An undefined “ERP connection” line does not enable offer comparison.

Acceptance work includes ordinary cases and actual exceptions. We recommend estimating sample preparation, execution, anomaly analysis and retesting after correction. Keep a separate line for the test record and handover. Training limited to standard invoice creation does not cover daily rejections and disputes.

Internal time belongs in the budget even when no supplier invoices it. Staff provide data, validate trials and handle initial exceptions. We separate this time from fees and subscription costs. Finance can then see total workload and organise availability at each stage.

The quote presents a range tied to explicit scope and assumptions. We recommend separating initial and recurring costs, included services and options. Entity and source counts remain visible. Comparison then concerns coverage and expected evidence rather than the subscription amount alone.

We deliver the flow map, test record and rejection procedure within our scope. Management designates the platform and organises operations; the vendor provides platform and support; the accountant classifies tax cases. Budgeting connects responsibilities to tasks and approvals so dependencies have an owner.

An approved platform (PA), formerly PDP for plateforme de dématérialisation partenaire, should be checked in the DGFiP list. The public invoicing portal (PPF) and directory provide public functions; they do not replace process preparation. We also recommend checking exports and exit arrangements before signing, as future migration can change total cost.

Budget decisions link each expense to a dependency or necessary control. We recommend separating operational readiness from workflow convenience. Data quality, coverage of an essential source and rejection handling are not secondary options. Management reporting can then be organised around the company’s own needs. This distinction helps finance explain why some work must precede a tool purchase and why an attractive feature cannot replace a missing regulatory flow.

Define indicators before launch: rejection rate, correction time, posting delay and receipt disputes. We recommend consistent scope and a baseline period. Measurement remains separate from a sales promise. A reduction in manual tasks should be compared with the control and exception-handling time remaining after automation. Keep the definitions unchanged between periods or explain any change, especially when transaction volumes, entity count or operating responsibilities have moved.

Review the budget when scope changes or a planned item differs. We retain initial assumptions and adjustment reasons: a new entity, additional connector, poorer data or training need. Management can decide next steps with an explained workload. A single price without these parameters would conceal necessary work and responsibilities. Document accepted changes before extending the project, so supplier costs and internal time remain visible in the same decision record.