How to use this e-invoicing compliance checklist
Your ERP team has to send and receive structured invoices under mandates that differ by country, start on different dates, and are still changing. This checklist is meant to turn that problem into a sequence of decisions and checks you can assign to owners. It is organized into functional, security, integration, operational and compliance requirements. Each item ends with a verification step, so you can tell whether the requirement is met in your own system, not just on paper. Work through the sections in order when you are scoping, then reuse them as a gate before each go-live date.
Treat every date, format and network named in the checklist as a question to confirm, not a fact to copy. This page does not set mandate dates, required formats or the rules of any network. Confirm current requirements with the national tax authority, the Peppol network or service provider you intend to use, and your ERP vendor, and record the version and date you checked. Mandates and their technical specifications have been revised more than once, so a figure you read in a summary may already be out of date. Ask each party in writing which version of a format or specification they expect you to support and when that changes.
For country-specific detail, use the sibling pages in this group. The German page covers XRechnung and Factur-X, the French page covers the approved platform model and e-reporting, the Polish page covers KSeF and FA(3), the ViDA page covers EU-wide rules for cross-border B2B, and the Peppol pages cover access points, SMP lookups and participant registration. Use this checklist to find the gaps in your ERP and integration layer, then use those pages to decide what each gap requires. Where a checklist item depends on a national rule, the verification step tells you which document or authority to ask.
Which functional requirements must the ERP meet before the first e-invoice
This table lists the ERP functions that must work before a first mandated e-invoice goes out, with the reason each matters and how to verify it. Read each row as a go or no-go gate, and confirm every item on a non-production copy before the first live issue date that applies to your company.
| Requirement | Why it matters | How to verify |
|---|---|---|
| Confirm applicable countries, sectors and start dates | Mandates differ by country, company size and sector, and dates can change, so the ERP rollout must follow the rules for each entity and flow | Map each legal entity and invoice flow to a written rule set, then confirm dates with the national tax authority or your tax adviser |
| Support structured formats based on EN 16931 | National formats such as XRechnung, Factur-X, FA(3) and Peppol BIS Billing 3.0 are built on the EN 16931 semantic model, so mismatched output fails validation | Generate sample invoices for each format and check them against the official validator for that country or network |
| Issue, receive, track status and handle credit notes | Mandates cover issuing, receiving and often status responses, and credit notes and corrections must reference the original invoice correctly | Run a full cycle on a test copy: issue, send, receive a response, issue a credit note, and confirm references and status in the ERP |
| Map tax codes, VAT treatment and currency | Wrong tax categories, reverse charge flags or currency codes cause rejections or incorrect VAT returns, especially for cross-border and foreign currency invoices | Test a matrix of domestic, intra-EU, export and reverse charge invoices with mixed currencies, then compare totals with the expected VAT report |
| Process rejected and failed documents | Networks and tax portals can reject or delay documents, and unhandled failures leave invoices unsent or duplicated | Force test rejections, confirm the ERP shows the error, blocks duplicate sending and allows correction and resubmission with an audit trail |
| Capture reporting and data-submission fields | National systems may need fields such as seller and buyer identifiers, payment terms, delivery data or transaction-level reporting that the ERP does not hold by default | Ask each authority or access point provider for the required field list, then check that the ERP stores and exports every field |
| Validate master data such as tax IDs and Peppol IDs | Missing or malformed tax IDs and Peppol participant IDs block sending, and stale customer records create rejected invoices | Run a validation report on customer and supplier records and confirm each ID against the registry or directory your network uses |
| Obtain written vendor or partner confirmation | Vendor claims about compliance can lag mandate changes, so the contract must state which versions and rules are covered | Request a written statement of supported formats, versions and network connections, and confirm the update process for each mandate change |
Master data that must be clean before go-live
Most e-invoicing rejections start in master data, not in the invoice template. A wrong tax ID, a missing Peppol identifier or an unassigned product code fails validation the same way on every invoice that uses it. The checks below are ordered from the legal entity outward to the customers, suppliers, products and contacts that depend on it.
Legal entity tax IDs and registration numbers
Each company code in the ERP needs the exact VAT number, national registration number and legal name as they appear in the official register. A mismatch in the seller block fails validation for every invoice issued from that entity. Verify by comparing each entity record against the national register extract and your VAT registration certificates, and confirm which identifier each country's format requires. Check group entities and branches separately, because a shared record can hide a second registration.
Customer and supplier tax IDs
Buyer and supplier VAT numbers are required on structured invoices in many national formats, and missing values are a common reason receivables and payables queues stall. Run a count of active customer and supplier records with an empty tax ID field, split by country, and resolve blanks before go-live. For EU counterparties, validate formats against the VIES service of the European Commission, and document which records are intentionally exempt, such as consumers or non-VAT registered parties.
Peppol participant identifiers
A Peppol participant identifier tells the network where to deliver an invoice, and it must match an entry in the SMP the receiver uses. Records that carry a plain company name but no identifier, or an identifier registered on a different access point, will bounce. Verify each trading partner by a lookup in the directory before the first live send, and record which identifier scheme each partner uses. Ask trading partners to confirm the identifier in writing, because a directory entry can exist for a different legal entity.
Billing and delivery addresses
Structured invoices require a complete postal address for both seller and buyer, with country codes in the expected format. Legacy records often hold free-text addresses, abbreviated countries or a single address line that cannot be split into the fields a format expects. Check a sample of records per country against the format's mandatory address elements, and separate billing addresses from delivery addresses so that goods shipment data does not overwrite the invoicing party.
Product and service codes
Line items often need a standard item classification or a buyer-specific reference, and some public buyers reject invoices that lack their own order or item identifier. Map every active product and service to the codes the target formats and buyers require, and check for duplicate SKUs that map to different tax rates. Count active items without a code or without a tax category, and fix them before enabling automated invoice generation, since bulk changes after go-live propagate to issued documents.
Contact points for error handling
When a network or authority rejects an invoice, someone must receive the error and act on it within the working day. Name a monitored mailbox or queue, and an accountable owner, for each legal entity and each e-invoicing channel. Test the route by sending a deliberately invalid invoice to a test environment and confirming who receives the rejection message. Without this step, rejections sit in a shared inbox and receivables continue to age.
What to confirm for each country in scope
Germany combines an obligation to receive structured B2B invoices with a phased obligation to issue them, and the formats you accept and send depend on how your ERP is configured. Treat the German rules as two separate workstreams, one for inbound processing and one for outbound issuing, because they often start at different points for different companies.
- Company scope and start dates: Confirm which legal entities must issue structured invoices, which only need to receive them, and the start date that applies to your turnover band and any exceptions.
- Formats: Establish whether you must issue XRechnung, Factur-X or both, and which structured formats your German trading partners will accept.
- Channel: Decide whether public-sector or partner flows require a Peppol access point or whether another exchange route is permitted for your counterparties.
- ERP output: Check that your ERP generates the mandatory fields, tax identifiers and buyer references that the chosen format validates against, and that it can ingest and store inbound structured invoices.
- Archiving: Confirm the retention and storage requirements for issued and received invoices under the German record-keeping rules, including the requirements for electronic storage.
Confirm each item with the national tax authority and its official e-invoicing guidance, then use the Germany sibling page for the detailed build steps.
France is moving to a reform that requires companies to issue and receive e-invoices through an approved platform and to report transaction data to the tax administration. Your ERP does not talk to the tax authority directly in most designs, so the platform choice and the data your ERP can supply become the critical questions.
- Company scope and start dates: Confirm which company sizes and transaction types fall under each stage of the reform, and the start date that applies to your entity.
- Platform role: Determine whether you will use an approved platform as a service, connect your ERP through its API, or operate the integration yourself, and confirm which platform types the tax administration recognizes.
- Format: Confirm which structured formats the reform accepts for issuing and receiving, including whether Factur-X is in scope for your flows.
- E-reporting data: List the transaction and payment data your ERP must hold so that it can be reported, including data for transactions that are not invoiced through the platform.
- Official source: Record the authority's current technical specifications and FAQs, and check them again before each release because the reform's technical details are published in stages.
Confirm each point with the French tax administration and the official specifications, then use the French reform sibling page for the connection steps and the e-reporting design.
Poland's KSeF is a national clearance system in which structured invoices are submitted to a central government system and receive an official number. The ERP design therefore depends on authentication, the mandated XML structure and how your team handles the national number in later accounting steps, not only on file generation.
- Company scope and start dates: Confirm which taxpayer categories must use the system in each phase and the start date that applies to your company.
- Structure and format: Confirm the XML schema version currently required, the mandatory fields and the rules for corrections, credit notes and advance payments.
- Authentication: Establish how your integration will authenticate to the system, who holds the credentials and how they are rotated and protected in a self-hosted environment.
- Channel and Peppol: Determine whether any of your flows also require Peppol or other exchange channels, and whether KSeF replaces them for domestic invoices.
- ERP output: Check that your ERP stores the national number against the invoice, can handle receivables and payables that reference it, and keeps the submitted XML as the record of what was filed.
Confirm each point with the Polish Ministry of Finance guidance and the official KSeF technical documentation, then use the Poland sibling page for the connection and module decisions.
The EU VAT in the Digital Age framework sets common e-invoicing principles and a cross-border reporting model, while member states keep the power to mandate domestic e-invoicing. For a multi-country company, the practical question is how national mandates and the EU framework interact in each country where you trade, and which changes your ERP must absorb in each step.
- Country map: List every country where you issue or receive invoices, and identify which already have a national mandate and which are still preparing one.
- Framework timing: Confirm the dates in the ViDA text and in each national transposition, because the national rules can apply earlier than the EU-wide cross-border reporting step.
- Format baseline: Confirm the EN 16931 semantic model and the syntaxes each target country accepts, and identify where national extensions add fields.
- Cross-border reporting data: Identify which cross-border B2B transaction data your ERP would need to supply for digital reporting, and where that data is held today.
- Change control: Decide who monitors national changes, how often the ERP configuration is reviewed and how releases are tested with each country's format before they go live.
Confirm each point with the European Commission's published VAT material and the national authority in each country, then use the ViDA sibling page for the country-by-country ERP plan.
Integration requirements the ERP and network must meet
An e-invoicing setup is only as good as its weakest connection between the ERP, the access point or national platform, and the accounting ledger. The cards below cover the interfaces, credentials and posting logic that have to work end to end before a mandate date, and how to prove each one with a test.
Documented interface to the network
Confirm how the ERP hands an invoice to the access point or national platform: a documented API, a file drop, or a vendor connector. Ask the access point or platform operator for the interface specification and version it supports, and check whether the ERP can produce the exact format it expects. Verify with a test transmission of one sample invoice per format and document type, then keep the logged acknowledgment or status response as evidence that the handover completed.
Certificate and credential handling
Each connection to a network typically relies on credentials, certificates or tokens that expire and must be rotated. Record who owns each credential, where it is stored, and how renewal is scheduled and tested. Confirm with the operator which certificate type is required and how revocation is handled. Verify by rotating a test credential in a non-production environment and confirming that transmissions still succeed afterward.
Odoo API access requires the Custom plan
External API access in Odoo is available only on the Custom plan, which is also the only plan that can be hosted on Odoo.sh or on-premise. A self-hosted Odoo deployment that must push invoices through an external connector therefore needs this plan confirmed in writing before design starts. Check that custom modules needed for e-invoice fields are supported on the same plan. Verify by confirming the plan in the subscription and running a test API call from the connector against a staging database.
ERPNext Server Scripts and hosting limits
From version 15, ERPNext Server Scripts are disabled by default and must be enabled with the server_script_enabled setting. Frappe Cloud public shared benches do not allow them, so validation or mapping logic written as Server Scripts needs a self-hosted or dedicated environment. Decide where mapping logic lives before choosing a hosting model. Verify by enabling the setting in staging and running a document event that posts a sample invoice.
Inbound posting without retyping
Inbound invoices should create supplier invoices in accounting directly from the structured data, with the supplier identified by tax ID or network identifier and the lines mapped to accounts and taxes. Define which fields are mapped automatically, which trigger a review queue, and which reject the document. Verify with a set of sample inbound files, including a credit note and a file with a missing supplier, and confirm that each lands in the expected state without manual keying.
Logged acknowledgments and error paths
Every outbound and inbound document needs a stored status trail: transmitted, accepted, rejected, or failed, with the timestamp and the network reference. Define who receives a rejection, how it is resubmitted, and how the original and corrected invoice are linked in the ledger. Verify by forcing a rejection in a test environment and confirming the alert, the resubmission and the audit entry all appear.
Security requirements for invoice data and access
E-invoicing puts tax data, customer records and signing credentials in one pipeline, so the same controls must hold from the ERP to the access point. The cards below cover the controls auditors and trading partners ask about first, and the checks to run before go-live.
Encryption in transit and at rest
Invoice files, XML payloads, attachments and database backups all carry customer and tax data. Check that traffic between the ERP, the access point, the SMP and any validation service uses current TLS, and that database volumes, object storage and backups are encrypted with keys you control. Confirm where invoice copies sit during retries and error queues, because failed messages are a common place where unencrypted copies persist.
Multi-factor authentication for all access
Anyone who can issue, approve, correct or download invoices should authenticate with multi-factor authentication, including administrators and vendor support staff. Apply it to the ERP web interface, the access point administration console and the SMP management tools. For covered financial institutions, the FTC Safeguards Rule at 16 CFR 314.4 requires multi-factor authentication for any individual accessing any information system, so confirm scope with counsel.
Logging of user and system activity
Keep an audit trail of who created, changed, cancelled or resent an invoice, and of configuration changes to the access point and SMP. Logs should be tamper-resistant, retained for the period your tax and archive rules require, and reviewed by someone outside the team that operates the system. The FTC Safeguards Rule requires logging of the activity of authorized users for covered institutions. Ask your ERP vendor which events are logged by default and which need configuration.
Change management for mapping and validation rules
Tax mappings, Schematron validation rules, tax code tables and numbering sequences change as mandates evolve. Treat each change as a controlled release: written request, peer review, test against sample invoices from each country, approval and rollback plan. The FTC Safeguards Rule requires change management procedures for covered institutions. Ask whether ERP customizations and server scripts can change invoice content without going through this path.
Signing keys and transport certificates
Peppol access point certificates, AS4 transport keys and any digital signature keys used for invoice output are high-value credentials. Store them in a hardware-backed key store or a managed secrets service, restrict who can export them, and record an owner and expiry date for each. Build an alert for certificate expiry well before the deadline, since a lapsed certificate stops invoice exchange. Confirm the rotation and revocation procedure with your access point provider or internal PKI team.
Separation of test and production credentials
Test and production environments need separate credentials, separate certificates and separate trading partner identifiers in configuration. Copy production databases to test only after removing or neutralizing live customer data, and keep test access point endpoints out of production configuration. Odoo documents database duplication with neutralization for test copies, which is one way to support this. Review which accounts can switch environments, because a single shared admin login defeats the separation.
How to test with trading partners before a mandate applies
Partner testing is where most e-invoicing projects find their master data and format faults, so treat it as a project phase with its own exit criteria rather than a final check before go-live. Build a test matrix with one row per trading partner, country and document type: domestic invoices, credit notes, corrections and any sector-specific variant each partner expects. For every row, record the sender and receiver identifiers, the format and network used, the expected outcome and the owner who signs it off. Use test participant identifiers agreed with each partner or access point provider, and confirm in writing which test environment each one points to before any document is sent.
Rejections are the most useful output of testing, so plan how they reach the ERP. Capture the exact rejection or validation message from the network or national platform, map each error to the field in the ERP that caused it (typically a tax ID, a buyer reference, a Peppol participant ID, a unit code or a tax category), and decide who corrects it: finance, master data or the integration team. Rehearse credit notes and corrections as deliberately as standard invoices, including the link back to the original document, because these are where numbering, tax treatment and archiving rules most often diverge. Confirm the exact field names and validation rules with each access point provider and the national platform, since they change as mandates evolve.
Odoo major upgrades on Odoo Online and Odoo.sh are mandatory every two years, according to the Odoo upgrade documentation, and the upgrade service produces an upgraded test database that should be tested before production. Treat that test database as a regression target: rerun the full test matrix against it, compare outputs to the last approved run, and check that custom modules, e-invoice connectors and document templates still produce valid files. Schedule the rerun before the upgrade window, not after it, and keep the results with the change record so auditors can see the evidence for each version in use. The Odoo upgrade documentation sets out the upgrade path and the test database process.
Operational requirements and how to verify them
This table lists the ongoing operating requirements for a self-hosted e-invoicing setup, who should own each one, and how to verify it with evidence. Read it after the country-by-country checklist, because the controls keep working after go-live when formats and mandates change. The main takeaway is that most failures come from unowned ongoing work, such as unmonitored transmission failures or ERP versions that fall out of support.
| Requirement | Owner | How to verify |
|---|---|---|
| Monitoring of transmission failures and backlog | Platform or integration team | Review a dashboard or log export showing sent, received, rejected and queued documents by day, with alerts that reach a named on-call contact |
| Named owner for mandate changes and format updates | Finance systems lead with tax advisor input | A written owner and deputy, plus a dated register of national rule changes that the team has reviewed and tested |
| ERP release policy with Odoo support windows | IT operations and ERP product owner | Written policy naming the version in use. Odoo 20.0 standard support is planned until September 2029, Odoo 19.0 until September 2028 and Odoo 18.0 until September 2027, per Odoo's support documentation |
| Odoo SaaS release cadence | ERP product owner | Test plan showing each Odoo SaaS release is validated in a non-production copy before it reaches live e-invoicing flows, since SaaS releases arrive every two to three months |
| ERPNext supported versions | ERP product owner | Confirm the installed version on the supported versions page: version 15 is planned to be supported until the end of 2027 and version 16 until the end of 2029 |
| Archive retention as required by applicable law | Records or compliance owner with legal counsel | Retention schedule per country and document type, mapped to the law that applies. SEC Rule 17a-4(b) is one example that applies only to broker-dealers, so confirm which rules apply to you |
| Backup and restore tests of archived invoices | Infrastructure team | Dated restore test that recovers a sample of archived invoices with their original files, metadata and signatures, and checks that they still validate |
| Incident path for rejected or late documents | Accounts receivable and payable leads with the integration owner | Runbook covering triage, resubmission, customer or authority notice, and root-cause record, tested with a simulated rejection before go-live |
The order to finish this checklist in
This sequence moves from confirming legal scope to proving the ERP works with real trading partners, so each step hands a defined output to the next. Skipping ahead usually means rebuilding invoice formats or master data after testing has already started.
Confirm countries, sectors and start dates
Start by confirming which countries, sectors and company sizes your mandates apply to, using the official government or tax authority sources for each jurisdiction rather than secondary summaries. Tax and compliance leads should own this step, with legal counsel reviewing anything ambiguous. Confirm each start date and any transition period, and record which rules apply to domestic sales, cross-border B2B and inbound invoices separately. It is done when you hold a dated jurisdiction matrix with a named source and reviewer for every line.
Freeze entities and document types in scope
Using the matrix from the first step, list every legal entity, branch, sales channel and document type that will issue or receive structured invoices, including credit notes, corrections and any recurring or subscription invoices. Finance owns the list and IT validates which ERP companies and journals map to each entity. Decide which flows stay out of scope and record why. It is done when a signed scope document lists each entity, document type and flow, with an agreed change process for later additions.
Clean master data and set identifier rules
Audit customer, supplier, product and tax master data for missing or malformed tax IDs, VAT numbers, legal identifiers, addresses, currency and unit codes. Set written rules for which identifiers are mandatory per country, how Peppol participant IDs are assigned and who may create or change a partner record. Duplicate records in the ERP will cause rejected or misrouted invoices, so resolve them before testing. It is done when a master data report shows the exception count per field and the owners have closed or accepted each exception.
Choose the transmission route and platform
Decide whether each country and flow will go through a national platform, a Peppol access point you run yourself, a service provider or an ERP vendor's network. Use the questions in the e-invoicing RFP guide to compare coverage, accreditation, validation, error handling, archiving, monitoring and support terms. Confirm with each provider which formats they produce and what they charge for each document, and check whether your ERP version supports the chosen route. It is done when a decision record names the route per country, the accepted vendor terms and the open items that could change the design.
Build and test in a non-production copy
Build the output and inbound processing in a copy of the production ERP, never in production itself. Keep test copies free of live personal and financial data where the ERP supports it, and agree test cases with your trading partners and your access point or platform provider. Cover valid invoices, rejections, credit notes, duplicates and corrections, and confirm that validation errors reach a person who can act on them. It is done when a partner test log shows each test case, the result, the retest and the sign-off from the business owner.
Prepare archive, monitoring and change control
Before go-live, define how issued and received structured invoices, their validation results and acknowledgments are stored, how long they are kept under each applicable rule, and who can retrieve them during an audit. Set up monitoring for failed transmissions, rejected documents and certificate or account expiry, and assign an owner for responding to each alert. Create a change process that covers mandate updates, format versions and ERP upgrades, since these will recur. It is done when the archive design, monitoring runbook and change calendar are approved, and a go-live checklist confirms each item.
What buyers ask before hiring outside help for e-invoicing
What drives the cost of e-invoicing compliance work?
The main drivers are the number of countries and mandates in scope, how heavily the ERP has been customized, the number of trading partners that must be onboarded and tested, the quality of tax ID and Peppol ID master data, and whether you buy an access point service or run your own. One-time work usually includes format mapping, validation rules, inbound processing and partner testing. Recurring costs depend on the network model, such as per-document fees from a provider or the operating effort for a self-run access point, plus certificate renewals and monitoring. Ask for a quote that lists each country, format and network separately, and states who pays for each line.
How long does e-invoicing readiness take for an ERP?
The duration depends mainly on the confirmed mandate dates for each country you trade in and on how quickly your trading partners can complete testing. Confirm the dates with your tax advisors or the relevant authority first, because they can change. Then sequence the work: master data cleanup, format mapping, inbound processing, archive design and partner tests. Without confirmed dates and named partner contacts with testing windows, no reliable schedule exists, so treat any early estimate as a planning placeholder and revisit it once the dates and contacts are fixed.
What does the company need to provide for this work?
The work needs several named owners on the company side. Finance owners should confirm VAT treatment, invoice content rules and archiving obligations. IT contacts need ERP administrator access, a non-production copy of the system and a way to connect to external networks. Sample invoices in every current format, including outbound and inbound examples, let the team test parsing and validation early. Partner contacts with technical testing windows are needed for the trading partners you send to and receive from. Master data owners must be available to correct tax IDs and Peppol IDs.
Can an internal team complete e-invoicing preparation without outside help?
A team with ERP administration skills, tax knowledge and integration experience can handle preparation, particularly for one country and one format. The work becomes harder when several countries apply, when the ERP contains custom code, or when you plan to operate an access point yourself. Check whether the team has already tested inbound parsing, validation error handling and archive retrieval, and confirm who owns each control after go-live. Outside help is often most useful for specific gaps, such as partner testing, hardening, documentation of controls or preparing evidence for an independent assessment.
Which questions separate ERP platforms on e-invoicing support?
Ask which countries and formats the platform supports natively and which need add-on modules or third-party connectors. Confirm whether Peppol sending depends on a vendor proxy or can connect to an external access point, since that decides your dependency and data path. Ask how inbound invoices are validated, how errors are reported and who fixes them. Find out how the vendor handles mandate changes and whether those updates are included in your subscription. For on-premise Odoo, the upgrade service requires an Enterprise subscription, and Community users do not have access to it, so confirm who carries the update effort in your model.
Does DeployOpen issue e-invoicing compliance certificates?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. In practice, the work can include configuring and documenting controls, setting up archiving, preparing test evidence and writing operating runbooks, all agreed in a written scope before work starts. Ask any provider, including DeployOpen, which of its deliverables an independent body would review and what the assessor will need from you.
What breaks first when an ERP starts receiving e-invoices?
In most ERPs, the first failures involve master data. Supplier records may lack a tax ID, the trading partner may not be registered on the network under the Peppol ID you stored, or the incoming file may not match the expected format syntax. Other common problems include rejected files that never reach an accounting queue, duplicate invoice numbers, and gaps in the record that a reviewer later needs. Test with a set of real supplier files from each partner before go-live, log every rejection with a reason, and confirm that the archived copy matches what was received.
How DeployOpen scopes and delivers e-invoicing readiness
DeployOpen works on e-invoicing readiness as a fixed-scope engagement inside your own infrastructure. We turn the checklist into a written scope covering your ERP, the countries and formats that apply, and the partners you must test with, then build, test, document and hand it over.
How we scope
- Map every country and entity where your ERP issues or receives invoices, against the requirements in this checklist
- Record which invoice formats, networks and master data fields each country and trading partner needs
- Agree in writing the systems in scope, deliverables, testing responsibilities and timeline before work starts
- Confirm with your tax and legal advisers which mandate dates and thresholds apply to your entities
How we build
- Configure tax IDs, Peppol IDs and customer and supplier master data with validation rules at entry
- Set up inbound invoice capture, validation and error queues so rejected documents are visible to finance
- Connect the ERP to the access point or national platform you select, using your own credentials and certificates
- Test outbound and inbound documents against partner test environments and record the results
How we hand over
- Deliver configuration records, data mapping tables and validation rule documentation for your audit file
- Document archiving settings, retention periods and how stored invoices can be retrieved and checked
- Train finance and IT operators on monitoring, error handling and the change steps for future mandate updates
- Provide a test evidence pack listing each country, format and partner tested and the outcome
How we support
- Offer ongoing support and upgrades as a retainer when mandates, formats or ERP versions change
- Review validation rule and format updates against your written scope and agree changes before deployment
- Keep ERP and integration components patched and backed up under the terms agreed in your support plan
- Ask your compliance team to confirm the evidence they need, since DeployOpen prepares evidence but does not issue audit reports or certifications
