E-invoicing solution RFP questions for ERP buyers

E-invoicing solution RFP questions to ask before you choose a partner

If your ERP team has to meet e-invoicing mandates in several countries, the RFP should test six things: country and format coverage, access point accreditation, validation and error handling, archiving, monitoring, and change handling as mandates evolve, plus the support terms that cover all of them. Many proposals look alike on the first page, so the differences sit in the answers to specific questions. Send the same written scope to every bidder, including the countries, ERP version, expected monthly document volumes and whether the access point must be self-hosted or can be a service. Ask each bidder for evidence (a test transcript, a sample validation report, a runbook excerpt, a named reference that can be verified) rather than a statement that they can do it. Then score every answer against one fixed list so the comparison is consistent.

Ask about coverage in writing, country by country. For each market, the bidder should name the format (for example XRechnung, Factur-X, FA(3), or an EN 16931 based syntax), the network or channel, and the dates they are building to, and say which items depend on the national authority. Confirm whether Peppol participation is through the bidder's own access point, a third party, or the ERP vendor's network, and ask who holds the Peppol certificates and accreditation. DeployOpen plans, implements, integrates, hardens and supports self-hosted platforms and prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, and independent auditors and certification bodies make those decisions. Any RFP answer that promises certification should be treated as a red flag. Scope, deliverables and timelines are agreed in writing before work starts, so ask bidders to put every commitment in their proposal.

Which questions reveal whether an e-invoicing setup will hold up?

Which countries and invoice formats does the proposed e-invoicing setup actually cover?

A credible answer names each country, the mandate it must meet, and the exact format it produces and accepts, such as EN 16931 syntax, Factur-X for France and Germany, XRechnung for German public sector buyers, Peppol BIS Billing 3.0 for cross-network exchange, or FA(3) for Poland's KSeF. Ask the bidder to show a sample output per format and state which countries are only planned. Vague phrases like "all EU countries supported" should prompt a follow-up asking for a dated list. Confirm each mandate's start date against the official source at the time of purchase, because rules change.

Does the bidder run its own Peppol access point, and what accreditation does it hold?

The answer should say whether the bidder operates an access point and SMP itself, or routes documents through a third-party provider, and name the software involved, such as Oxalis-NG for AS4 messaging and phoss SMP for capability lookup. Ask for the Peppol certificate chain, the accreditation authority and the participant identifiers used for your company. Confirm in writing who holds the certificates, who renews them, and what happens to participant registration if the provider changes. Do not accept a claim of accreditation without a verifiable reference.

How does the system validate invoices and report errors before and after sending?

Good answers describe validation at three points: before the ERP posts the invoice, at the XML schema and business rule level against EN 16931 and the national rules, and at the network level after transmission. Ask for an example error log showing the rule that failed, the document identifier, the timestamp and the retry status. Ask how rejected invoices return to a work queue, who is notified, and how the bidder distinguishes a rejected message from a delivered one with a missing acknowledgement. Ask whether validation rules are versioned so a historical invoice can be re-checked.

How are e-invoices archived, and can they be retrieved for an audit years later?

The answer should name the storage approach, the retention period set for each jurisdiction, and whether the original structured XML and any visual PDF are stored together with their validation evidence. For Germany, ask how the setup supports GoBD-compliant storage. For US-linked records, the SEC Rule 17a-4(b) sets a minimum of three years for certain broker-dealer records, with the first two in an easily accessible place. Ask for a retrieval test on a sample invoice from several years ago, and confirm who holds the encryption keys.

What monitoring shows that the access point and ERP connector are working?

Ask which signals are monitored: queue depth, transmission failures, certificate expiry dates, SMP lookup failures, and the time between sending and acknowledgement. The bidder should name the tooling, the alert recipients and the escalation path. For a self-hosted setup, ask who watches the access point at night, and whether the bidder provides a runbook. Request a sample dashboard or alert list and confirm whether monitoring is included in the fixed scope or sold as a retainer. Ask how the system is tested end to end with a trading partner before go-live.

How will the setup change when a mandate or format version changes?

The bidder should describe a written change procedure: how it tracks official publications, who assesses impact on your ERP, how changes are tested on a non-production copy, and how the release is approved and rolled back. For Odoo, ask how the bidder plans for the major version cycle, since Odoo 20.0 standard support runs to September 2029 and Odoo standard support covers the first three years after a major release. For ERPNext on Frappe, ask which version is in use, because Frappe warranty requires a listed version and a matching Frappe Cloud support plan. Ask for the date of the last change to the procedure.

Who maintains the ERP connector, and how does it fit the ERP's version policy?

Ask whether the connector is the ERP vendor's native module, a community add-on, or custom code, and who supports each. For Odoo, check whether the feature sits in Community or requires an Enterprise subscription, since the Community edition has no access to the upgrade service. For ERPNext, ask whether custom Server Scripts are used, because from version 15 they are disabled by default and must be enabled with the server_script_enabled setting. Confirm the licensing cost of each component and who signs each subscription.

What support terms and fixed-scope deliverables should a written proposal include?

A proposal should list deliverables, the countries and formats in scope, the testing evidence provided, the handover documents, and the support window after go-live. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and monitoring can be contracted as a retainer. Ask for the response expectations for incidents and mandate changes, and whether they are written as service levels. Cost drivers include the number of countries, document volume, the number of ERP entities, and whether the access point is self-run or provided by a third party. Ask for a quote that separates one-time implementation from recurring fees and third-party subscriptions.

Which vendor answers should stop the shortlist?

Vendor answers in an e-invoicing bid often sound complete while hiding gaps in country coverage, network access, error handling and long-term support. The six patterns below are the ones that most often separate a credible proposal from a risky one for a regulated buyer running a self-hosted ERP.

Country lists without dates

A proposal that says it covers Germany, France, Poland and the EU but gives no go-live dates, scope per invoice type or transition periods cannot be planned against. Mandates differ by country, by buyer size and by whether the invoice is domestic or cross-border. Ask for a country-by-country table with the legal basis, the effective date for each obligation and the format and network used. Ask the vendor to name what it will not cover yet.

Accreditation claims without evidence

Statements such as "Peppol ready" or "certified" are not enough. A regulated buyer needs the named access point, the certificate scheme in use, the accreditation status and the party responsible for keeping both current. If the vendor routes documents through a third party, the bid should say so and state who holds the contract, the certificates and the incident contact. Ask for the access point identifier and the proof of accreditation in writing before shortlisting.

Silent handling of rejected invoices

Rejections from a tax authority, a clearance platform or a buyer's access point are routine, and each one carries a legal clock. A bid that does not describe how rejected documents are reported, who sees them, how they are corrected and resubmitted, and how the original is kept will leave the finance team reconciling by hand. Ask for a worked example of a rejected invoice from submission to resolution, including the audit trail and the alert that reaches an owner.

Archiving without retention or immutability

Archiving that is described only as "stored securely" does not answer what a records auditor will ask. Buyers need the retention period for each record type, where the archive sits, whether stored documents can be altered or deleted, how the original structured file and its rendered copy are kept together, and how access is logged. Retention rules for broker-dealer records, for example, are set in SEC Rule 17a-4(b), so the bid should show how the vendor's archive maps to the rule that applies to the buyer.

Mandate updates without a change process

Formats, schemas and deadlines change, and the vendor's answer to change is part of the risk. Ask how the vendor tracks changes to national rules, how it tests a new version against trading partners before production, who approves the change and how it is documented for your change management records. A promise to "keep up with regulations" without a dated release process, a test environment and a rollback plan should count against the vendor.

Support terms that hide dependencies

Support pricing often depends on components the headline price does not show, such as an enterprise edition of the ERP, a hosted version that must be used for security patches, or a support plan that must match the release. Ask which ERP edition, which hosting model and which support plan the quote assumes, how long each supported version receives security fixes and what happens when a version reaches end of life. Written answers on these points belong in the scope, not in a later invoice.

How answers differ for Odoo, ERPNext and an external network

Odoo's Community edition is licensed under LGPL-3.0, but e-invoicing and most production features depend on the paid Enterprise edition, whose source code is not public and requires a subscription or partner access. The hosting tier matters as much as the license. Odoo's pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company, Odoo Studio, external API access and custom modules. Ask the vendor which tier your connector and Peppol module need, and whether that tier is in the quote.

Licensing: Ask which Enterprise modules the Peppol or e-invoicing function depends on, and whether a proxy or hosted service from Odoo is required for network access.
Hosting tier: Confirm that the self-hosted deployment is on the Custom plan, with on-premise or Odoo.sh activation through the subscription code.
Upgrade path: Ask which supported version your connector targets. Standard support covers three years after a major release, and Odoo 20.0 standard support is planned until September 2029. Ask who tests the upgraded database before production.
Connector ownership: Ask whether the Peppol module is Odoo-maintained, whether custom connector code is yours, and who fixes it after an Odoo upgrade.

Check whether any Peppol capability is delivered through an Odoo-hosted proxy, and what happens to your invoices if that dependency changes.

What archiving and audit evidence should a proposal show?

The buyer's own retention duties should decide the archive design, not the bidder's default settings. Ask each bidder which records their proposal would hold (issued and received invoices, attachments, validation results, transmission receipts, and the master data that explains them) and which rule sets the retention period for each. The research on this point is sector-specific: SEC Rule 17a-4(b) requires broker-dealers to preserve certain records, including bills receivable or payable and bank statements, for not less than three years, with the first two in an easily accessible place. A non-broker-dealer buyer may face different periods under tax or local law, so the proposal should name the rule it designs against and confirm the period with the buyer's own counsel or tax advisers.

The FTC Safeguards Rule at 16 CFR 314.4 is relevant where the e-invoicing environment holds customer financial information. It requires covered financial institutions to log the activity of authorized users and to adopt change management procedures. For an RFP, this means the bidder should show who can change the ERP invoice templates, validation rules and access point configuration, how those changes are approved and recorded, and where the logs are kept. Ask for sample retention settings, sample access logs with user, action and timestamp fields, and the export procedure an auditor would follow, including how a single invoice's full history can be produced in a readable form.

A credible proposal demonstrates evidence, not outcomes. Ask bidders to walk through a live or recorded export for a sample period, showing the archived files, their hashes or integrity checks, and the audit trail that links each invoice to its transmission status. Ask who holds the archive keys, where the archive is stored (in the buyer's own infrastructure or a third party's), and how it is restored if the ERP is upgraded or replaced. Make no assumption that any proposed setup will pass an audit: the buyer's auditor decides what is sufficient, and the proposal should state clearly which evidence it produces and which items the buyer must confirm with that auditor.

How to run the RFP in four rounds

This sequence moves a buyer from a loose vendor list to a comparison built on written answers, tested behavior and verified references. Each round narrows the field and produces evidence that a quote can be checked against.

Send the written scope and question list
The buyer sends one written scope to every candidate partner, covering the ERP version in use, the countries and invoice formats required, the access point model, archiving obligations and the support expectations. The question list groups questions by country and format coverage, access point accreditation, validation and error handling, archiving, monitoring, change handling as mandates evolve, and support terms. Candidates confirm in writing that they received the same scope. The step is done when every candidate has acknowledged the same document and no candidate is answering a different question set.
Collect written answers with named evidence
Each candidate answers every question in writing and names the evidence behind each answer, such as a configuration export, a runbook excerpt, a test report, a named tool or a described log format. Vague answers such as 'we support all countries' are returned for a specific answer, with the country, format and network named. The buyer checks each claim against the vendor's own documentation and asks the candidate to confirm which items depend on third parties, such as a Peppol service provider or a national portal. The step is done when every answer is marked as confirmed, partly confirmed or not offered, with the evidence attached.
Run a scripted demo on a test database
The buyer asks each shortlisted candidate to run a scripted demo on a copy of the ERP test database, not on a sales environment. The script includes issuing a sample invoice, submitting it through the proposed access point, and deliberately submitting a sample invoice that fails validation, such as a missing tax identifier or a wrong unit code. The buyer watches how the error is reported, where it is logged, how the invoice is corrected and resubmitted, and whether the original record stays traceable. The step is done when the buyer has a recorded run for each candidate and a list of any steps the candidate could not perform live.
Check the change handling plan against the demo
Before references, the buyer asks each finalist to show how the proposed setup would absorb a change in a mandate, a format version or an ERP upgrade. The buyer asks which configuration would change, who tests it, how it is rolled out to a test database first, and how the rollback works. The buyer also checks how the candidate will track the ERP vendor's upgrade cycle and the access point's software updates. The step is done when the finalist has written down the change process and the buyer has confirmed that it matches what was seen in the demo.
Ask for references and a reference architecture
The buyer requests references from comparable deployments and a reference architecture diagram for the proposed setup, showing the ERP, the access point, the SMP lookup, the archive, the monitoring stack and the network boundaries. The buyer confirms with each reference whether the project was delivered as described, whether the error handling worked in production, and how issues were resolved after go-live. Where a candidate cannot name references because of confidentiality, the buyer asks for an anonymized description that can be verified. The step is done when the architecture is reviewed by the buyer's security and integration leads and each reference has been contacted.
Request the final quote from the written scope
Only after the earlier rounds does the buyer ask for a final quote, and the quote is tied to the written scope agreed in round one. DeployOpen does not publish a price list, so a quote follows from the written scope, deliverables and timeline agreed in writing before work starts. The buyer asks each candidate to separate one-time implementation work from recurring items such as support, upgrades, hosting, access point fees and per-document charges, and to state what changes the price. The step is done when each finalist has returned a quote that maps line by line to the scope, and the buyer can compare them on the same basis.

How to score each area so bids compare fairly

Score every bid against the same six areas and the same weights, set before responses arrive. The buyer sets those weights from its own country, format and volume profile, so a bid for a single-country B2B flow is not judged on the same mix as a multi-country group. Each card below is one area to weight and check.

Country and format coverage

Weight this area by the mandates that apply to your legal entities today and the ones due in the next planning window. Ask each bidder to list, country by country, which formats it issues and receives (for example, structured formats used in Germany, France or Poland) and which network each one uses. Ask for evidence of live handling, not a roadmap. A bid that covers your largest flow but not a smaller mandated country should lose points in proportion to that gap, and a missing country scores zero.

Access point accreditation

Ask whether the bidder operates its own access point or relies on a provider, and whether that provider holds the Peppol accreditation your network requires. Request the accreditation status, the Peppol identifiers used for your participants, and the certificate lifecycle owner. Confirm who handles certificate renewal, participant registration changes and onboarding of trading partners. Score a bid higher when the accreditation covers the exact network and country pairs in your scope.

Validation and error handling

Ask how each invoice is checked against the applicable schema and business rules before it leaves your system, and how inbound documents that fail are quarantined, returned or routed to a person. Request examples of rejection messages, retry rules and how a rejected invoice is traced back to its source record in the ERP. Weigh bids on whether the error process is documented, tested with trading partners and reportable to finance, rather than on the number of checks listed.

Archiving and retention

Score how each bidder stores the original structured file, the rendered human-readable copy and the validation record, and how long each is kept. Ask where the archive sits, who can read it, how it is protected against change and how a record is retrieved during an audit. For German and US-linked records, ask the bidder to map its archive to the retention rules you must meet, such as the three-year period under SEC Rule 17a-4(b) where it applies. Missing retention design scores zero.

Monitoring and audit logging

Ask which events are logged (sent, received, accepted, rejected, retried, certificate expiry), how alerts reach an operator, and who reviews them. Request sample dashboards and the retention period for logs. Where the setup is self-hosted, confirm which parts the bidder monitors and which remain your responsibility, including the access point, the ERP connector and the database. Score higher for bids that show user activity logs tied to the authorized users who touched each invoice.

Change handling and support terms

Mandates, formats and network rules change on fixed dates, so score how each bidder plans and tests changes. Ask for its process for applying a new format version, the test window with trading partners, the rollback plan and the service levels for incidents. Confirm the ERP version support dates the bidder depends on and who pays for upgrades. For example, Odoo 19.0 standard support runs until September 2028, so a bid built on that version should show how it moves to a newer release. Unanswered questions score zero.

What to confirm with the vendor and your own environment

Several facts that decide an e-invoicing design are not settled by the research behind this page, so the RFP must ask for them directly. First, confirm which mandates apply to your entities by country and date, including whether each obligation covers issuing, receiving, or both, and whether it is a clearance model, a network model or a reporting-only model. Check every date against the official tax authority publications for each country and against your own legal counsel, because national timetables and thresholds change and the vendor's roadmap is not a legal source. Ask the vendor to name the official source it uses for each country and the date it last reviewed that source.

Second, ask which access point, network or government platform the vendor uses for each country, and whether that connection is direct, through a third-party service provider or through a hosting arrangement inside the ERP vendor's own network. Then establish who holds the accreditation and the Peppol certificates. In some setups the vendor holds them and the buyer is a customer of that service, and in others the buyer's legal entity must be the registered party. Confirm which identifiers (tax IDs, Peppol participant IDs, government registration numbers) sit in your ERP master data, who maintains them, and whether moving to another provider later would require re-registration.

Third, ask how the vendor handles mandate changes and format updates. Request the written process for tracking changes to schemas, validation rules and national specifications, the notice period you receive, whether updates are included in the subscription or billed separately, and who tests them against your ERP version before they reach production. If your ERP is self-hosted, confirm which parts of the update are your responsibility, such as applying module versions, retesting custom code and keeping the access point software current, and write those responsibilities, and the response times for critical rule changes, into the contract.

What do buyers ask before hiring an e-invoicing partner?

What does an e-invoicing implementation quote usually cover?

A quote should separate one-time project work from recurring costs. The one-time part typically covers ERP configuration, mapping of tax IDs and participant identifiers, output in the required invoice formats, inbound processing, validation rules, archive setup and testing with trading partners. The recurring part covers software subscriptions or support plans, hosting, network or access point fees charged per document, monitoring and any retainer. Ask who is paid for each line: the ERP vendor, a network or service provider, the implementation partner, or your own staff. Self-hosting an open-source core carries no license fee in itself. Odoo Enterprise, however, requires a subscription, and Frappe Cloud hosting is priced separately. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and a quote follows from that written scope.

How long does an e-invoicing rollout take and what drives it?

The duration depends on the written scope, so ask the partner for it in writing rather than relying on a general estimate. The main drivers are the number of countries and mandates in scope, the formats each one requires, whether you run your own Peppol access point or connect to an external one, and how much the ERP has been customized. Data quality matters as much as configuration: missing VAT numbers or Peppol participant IDs in customer and supplier records slow every test cycle. The number of trading partners available for testing also sets the pace. If your ERP is on Odoo Online or Odoo.sh, the mandatory major upgrade every two years can collide with an e-invoicing project, so confirm the upgrade calendar before fixing dates.

What does our team need to provide for an e-invoicing project?

Your team supplies the decisions and access that the partner cannot make alone. Expect to name a business owner who signs off on invoice content, a tax or accounts receivable lead who confirms which mandates apply to each legal entity, and an ERP owner who approves configuration changes. Access is needed to a non-production ERP database, the cloud accounts or data center where the services run, and the security processes that approve certificates and keys. Master data must be cleaned up: tax identifiers, Peppol participant IDs, customer and supplier records. Finally, you need contacts at the trading partners who will exchange test invoices. Ask the partner to list these dependencies in the written scope with a named owner for each.

Can our internal team run e-invoicing without an implementation partner?

A team with ERP engineering and integration skills can build and run an e-invoicing setup, but the ongoing work is larger than the first go-live. Someone must track mandate changes by country, update formats, rerun validation, monitor failed transmissions and keep archives compliant. Network participation may require accreditation and certificates, which you should confirm with the network or service provider you choose. Vendor support also matters: Frappe's supported versions policy says customers must be on a listed version and subscribed to a matching Frappe Cloud support plan to receive warranty coverage from Frappe, and Odoo's standard support covers the first three years after a major release. Before deciding, compare the staff hours you can commit against the scope in writing.

What does a support retainer cover after e-invoicing go-live?

A retainer covers work after go-live that the buyer chooses to outsource, such as ongoing support, upgrades and continuous testing. It is separate from the fixed-scope project and is agreed in its own written scope. Ask the partner to specify which ERP versions it supports, how it handles a change when a country alters an invoice format, how often regression tests run after ERP minor releases, and how it documents each change for your audit trail. Ask for the response process in writing, including how urgent transmission failures are escalated. Also confirm whether the retainer covers the access point, the ERP, or both, since each carries its own upgrade path and support window.

What should a written e-invoicing scope list before work starts?

A useful scope names each country and format in play, such as XRechnung, Factur-X, KSeF FA(3) or Peppol BIS Billing 3.0, and the ERP versions and legal entities involved. It lists the inbound and outbound flows, the validation and error handling rules, the archive design and retention period your legal team has confirmed, the monitoring you expect, and the test plan with named trading partners. It should state what is excluded, such as mandates in countries not listed, and what happens if a regulator changes a format during the project. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any audit reports or certifications, so the scope should say which evidence you will hand to them.

Which ERP upgrades and support windows affect the e-invoicing plan?

The ERP's support window sets how long the integration can stay on one version. Odoo 20.0 was released in September 2026 with standard support planned until September 2029, while Odoo 19.0 has standard support until September 2028. Standard support includes security updates and bug fixes, and extended support afterwards is limited to Odoo.sh for select versions and on-premise. Odoo SaaS versions cannot use extended support. For ERPNext, version 15 is planned to be supported until the end of 2027 and version 16 until the end of 2029, and version 14 reached end of life on January 31, 2026. Ask the partner which version the scope targets and how a planned upgrade would be tested before production.

How DeployOpen scopes and supports e-invoicing evaluations

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For e-invoicing RFP work, that means turning vendor answers into a written scope, testing the setup against your own trading partners and mandates, and handing over documentation your team and auditors can use.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
We map each RFP question to a country, format, network and ERP module so gaps are visible early
The written scope names which mandates, access point options and archiving rules are in and out

How we build

We integrate the chosen ERP or accounting system with the e-invoicing network or access point you select
We configure validation, error queues and inbound processing against your own sample invoices
We test against trading partners and document the test cases and results for each country in scope

How we hand over

You receive configuration records, integration diagrams, runbooks and monitoring setup in writing
We document how mandate changes will be assessed and applied, with named owners on your side
Handover covers archive retention settings and the evidence your compliance team needs for review

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Retainers can cover ERP version upgrades and the validation rule updates that follow mandate changes
Support terms, response expectations and included scope are agreed in the written statement of work

E-invoicing solution RFP questions