In our previous article, Electronic Invoicing in France: What It Means for Your FileMaker Solution, we explored the impact of the French electronic invoicing reform and why compliance is about much more than simply generating electronic invoices.
One of the key lessons came from our own experience in Italy. After supporting dozens of companies in adapting their FileMaker-based ERPs, we discovered that every solution had evolved around its own business processes, workflows, and business rules. That flexibility is one of FileMaker’s greatest strengths.
It also means that every electronic invoicing project starts in the same place: understanding the existing ERP.
As we explain in our Client Wins story, generating the final electronic invoice was rarely the difficult part. The real work started much earlier, by assessing whether the ERP already contained the data, business information, and workflows required to support the new process.
This article builds on those lessons. Rather than focusing on the regulation itself, it provides a practical checklist to help you evaluate your FileMaker solution before discussing providers, integrations, or implementation strategies.
The checklist isn’t intended to provide a pass-or-fail result. Instead, it highlights the areas of your ERP that typically require attention when preparing for French electronic invoicing, helping you identify potential gaps before the project begins.
The checklist
Before discussing providers, integrations, or technical implementation, we always begin in the same place: reviewing the existing ERP.
The objective is simple. We want to understand whether the application already contains the data, processes, and workflows required to support electronic invoicing, and identify any areas that may need to be adapted.
The checklist below follows the same approach we use when assessing a FileMaker solution before starting an electronic invoicing project. While every ERP is different, the questions are remarkably similar.
1. Company & Customer Information
Electronic invoicing starts long before the invoice itself. Every electronic document needs to identify the parties involved using complete and consistent business information. Many FileMaker solutions already store customer and supplier data, but not always in the structure required for electronic invoicing.
The objective of this section is to verify whether your ERP can reliably identify companies, legal entities, and the information that will accompany every invoice.
Company Identification
Before an electronic invoice can be exchanged, every company involved must be identified correctly. Depending on the country and the business context, this may include legal entity information, tax identifiers, and other mandatory business data. The first step is therefore to verify that your ERP can store this information in a structured and consistent way.
Ask yourself
- Can your ERP store all company identification numbers required by your country?
- Are VAT numbers stored consistently?
- Can legal names differ from trading names?
- Can multiple legal entities be managed if necessary?
Why it matters
Electronic invoices rely on accurate business identification. Missing or inconsistent company information can prevent an invoice from being processed correctly and often requires changes to the existing customer structure.
Billing & Delivery Addresses
Electronic invoicing may require billing and delivery information to be managed separately. While many businesses use the same address for both, this is not always the case.
Ask yourself
- Can customers have multiple addresses?
- Are billing and delivery addresses managed separately?
- Can historical invoices preserve the original address?
- Can the correct address be selected for each invoice?
Why it matters
Many FileMaker solutions were designed around operational needs rather than regulatory requirements. If only one address is available, additional changes may be needed before electronic invoicing can be implemented.
Customer-Specific Information
Different customers may require different payment conditions, invoicing preferences, or additional business information.
Ask yourself
- Can payment terms be defined per customer?
- Can payment methods vary between customers?
- Can customer-specific invoicing preferences be stored?
- Can additional information be added without redesigning the ERP?
Why it matters
Electronic invoicing often exposes information that has always existed informally but was never stored inside the ERP.
2. Invoice Structure
An electronic invoice is generated from structured business data. If invoices exist primarily as printable documents rather than structured records, adapting the ERP may require more than simply exporting data.
Invoice Lines
Electronic invoices are generated from structured business data, not from a document layout. Every product or service should exist as a complete record containing the information required to describe the transaction accurately. This is one of the first areas we review when assessing a FileMaker ERP.
Ask yourself
- Are invoice lines stored as individual records?
- Does each line contain quantities, prices and VAT information?
- Can discounts be applied per line?
- Can the invoice totals always be reconstructed from the stored data?
Why it matters
The electronic invoice reflects the business transaction, not the printed layout. The underlying data structure must therefore be complete and consistent.
3. Payments & Financial Information
Payment information is often one of the biggest surprises during electronic invoicing projects. Many companies have historically managed payment terms outside the ERP or delegated them to accounting. Electronic invoicing requires these details to become part of the business process.
Payment Conditions
Payment information is often managed outside the ERP, especially in long-established business processes. Electronic invoicing brings these details into the transaction itself, making payment methods, terms, and due dates part of the information exchanged between systems.
Ask yourself
- Are payment methods managed inside the ERP?
- Are payment terms stored for each customer?
- Are due dates calculated automatically?
- Can multiple instalments be managed when required?
Why it matters
Incomplete payment information may require manual intervention or additional development before electronic invoices can be generated consistently.
4. Sales Workflow
Creating an invoice is only one step in the sales process. The ERP should be able to support the complete lifecycle of the document, from creation to corrections and status management.
Invoice Lifecycle
Creating an invoice is only one step in the sales process. Once an invoice has been issued, the ERP should be able to manage its entire lifecycle, including corrections, cancellations, credit notes, and historical records. Electronic invoicing introduces additional events and document relationships that should remain consistent throughout the process.
Ask yourself
- Can invoices be modified before sending?
- Can credit notes be linked to original invoices?
- Are cancelled invoices managed correctly?
- Can document history be preserved?
Why it matters
Electronic invoicing introduces new events and document relationships that often do not exist in traditional invoice management.
5. Purchase Invoice Workflow
Electronic invoicing affects both outgoing and incoming invoices. Receiving supplier invoices is frequently overlooked during planning, yet it often has the greatest operational impact.
Incoming Invoices
Electronic invoicing doesn’t only change how you send invoices. It also changes how you receive them. Instead of arriving as PDFs attached to an email, supplier invoices become structured electronic documents that need to be imported, stored, and integrated into your existing purchasing and accounting processes.
Ask yourself
- Can incoming invoices be stored within your existing purchasing workflow?
- Can they be linked to suppliers?
- Can attachments be preserved?
- Can users search and review received invoices?
Why it matters
Receiving invoices is not simply importing a document. The ERP must integrate incoming information into existing purchasing and accounting workflows.
6. Notifications & Workflow Management
Electronic invoicing creates a continuous exchange of information. The ERP should be able to understand not only that an invoice has been sent, but also what happens afterwards.
Status & Notifications
Electronic invoicing introduces an ongoing exchange of information between your ERP and the external invoicing ecosystem. Sending an invoice is only one step. Your application also needs to understand what happens afterwards, from successful delivery to validation, rejection, or other status updates.
Ask yourself
- Can delivery status be stored?
- Can rejection messages be managed?
- Can users understand why an invoice failed?
- Can workflows react automatically to status changes?
Why it matters
Sending an invoice is only the beginning. Managing responses from the electronic invoicing ecosystem is equally important.
7. Integration Readiness
Choosing an electronic invoicing provider is only one part of the project. Before discussing APIs or platforms, it is worth understanding whether the ERP is architecturally prepared to integrate with external services.
Integration Architecture
Electronic invoicing should become part of your ERP, not become your ERP. A well-designed integration keeps business processes separate from regulatory requirements, making the application easier to maintain as providers, standards, or regulations evolve over time.
Ask yourself
- Is business logic separated from regulatory logic?
- Can integrations evolve without redesigning the ERP?
- Can providers be replaced if necessary?
- Are external services isolated from core business processes?
Why it matters
A well-designed architecture reduces future maintenance, simplifies regulatory updates, and makes the ERP less dependent on a single provider.
Final Assessment
This checklist isn’t about passing or failing.
Most FileMaker solutions have evolved over many years to support the specific needs of a business. Finding gaps doesn’t necessarily indicate that something is wrong. More often, it reflects the fact that the application was never designed around the requirements of electronic invoicing.
Some organizations will only need to add a few data fields or adjust existing workflows. Others may discover that certain parts of the ERP, such as invoice management, payment handling, or supplier invoices, require a more structured approach.
The important point is not how many questions you answered “Yes.” It is understanding where your ERP is already prepared and where additional work may be needed before starting the integration.
The good news is that these questions can be answered before selecting an e-invoicing provider or writing a single line of integration code. In fact, that’s exactly where every successful electronic invoicing project should begin.
What Comes Next?
Once you have a clear understanding of your ERP, the next question naturally becomes: How should it connect to the French electronic invoicing ecosystem?
Many organizations start by choosing an e-invoicing provider. In practice, that’s only one part of a much broader project involving business processes, data flows, incoming invoices, notifications, and long-term maintainability.
