# How to read an ERP country-support claim Ask the supplier to identify the exact configuration behind its country-support claim. The name of an ERP family is only the first part of that answer. Editions, releases, local modules, external services and implementation choices can change the available workflow. Use this guide to turn a broad product statement into a capability record you can compare and test. The classification below is an editorial method, rather than a vendor certification scheme. **Diagram:** A capability depends on product context, local components, external services and configuration. Conceptual dependencies. A product-family name alone cannot establish the available workflow. ## Identify the product and deployment Record the full product name, edition and deployment model. Ask whether the feature applies to the proposed cloud service, private deployment or on-premises release. Keep distinct products separate even when they share a vendor. Documentation for Dynamics 365 Finance does not establish a Business Central feature. A SAP S/4HANA Public Edition page does not automatically establish Private Edition or Business One behavior. Ask the supplier to point to the product context in its source. Keep the exact release reference with the evidence. If the documentation describes a later release, record the upgrade dependency. ## Name the local components Identify each country package, vendor app, partner extension, mapping and report template. Record the publisher and support owner. Oracle's catalog distinguishes localization SuiteApps, tax engines and reporting apps. Use the actual component names rather than turning every Oracle-supplied extension into an unexplained "native" label. [Oracle, SuiteApps catalog](https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/article_3134602194.html) Microsoft distinguishes Microsoft-led Business Central localizations from partner-led localization apps. Preserve that distinction in the country record. [Microsoft, Business Central localization strategy](https://learn.microsoft.com/en-us/dynamics365/business-central/about-localization) For Odoo, record the major version and specific country modules. A fiscal localization package is a starting point for configuration; its existence does not establish every invoice or reporting workflow. [Odoo, fiscal localizations](https://www.odoo.com/documentation/19.0/applications/finance/fiscal_localizations.html) ## Identify external services and commercial scope Ask which functions require an access point, accredited platform, tax engine, filing service or local accountant. Name the contracting entity and interface for each. Record subscription requirements, volume limits and implementation services from the proposed commercial documents. Public documentation may describe a feature without resolving your entitlement to use it. Ask who maintains each interface when either supplier changes its API. Include responsibilities for mappings, credentials, incident escalation and historical data export. An external service should appear in the operating plan as well as the architecture diagram. ## Describe the actual capability Use a sentence with a subject, action and output: "The configured module generates outbound invoice type X and sends it through provider Y." Add receipt, reporting, correction and export as separate statements where evidence supports them. Preserve direction. A vendor can document supplier-invoice import without establishing customer-invoice transmission. Preserve document type too: a sales invoice, self-billed purchase and retail receipt may use different processes. SAP's DRC compliance-task matrix identifies country scenarios and source systems. Use the relevant entry, rather than treating a country name in the matrix as proof of every process. [SAP, supported DRC compliance tasks](https://help.sap.com/docs/cloud-edition/sap-document-and-reporting-compliance-cloud-edition/supported-business-scenarios?locale=en-US) ## Separate availability from evidence Record whether the supplier describes the feature as released, early access, preview, planned, discontinued or explicitly unsupported. Keep a separate evidence status for what you have checked or demonstrated. A published roadmap can be well sourced while the capability remains planned. An available feature can remain untested in your deployment. Neither condition should disappear behind a single "verified" badge. Record missing evidence as unresolved. Absence from a help index does not prove that a feature is unsupported or available only through partners. Ask for a more specific source before making that inference. ## Write a useful capability record Use this record for a product page or procurement comparison: - Product family, edition and deployment: - Release and minimum update: - Country and obligation: - Document types and direction: - Module, publisher and mapping revision: - External service and contract: - Setup and entitlement prerequisites: - Availability state: - Source, date and evidence state: - Demonstrated scenarios: - Limits and unresolved questions: If a field is unknown, state that explicitly. A precise gap helps a partner answer the question. A broad global-support statement usually starts another round of clarification. ## Validate the proposed configuration Ask the supplier to reproduce the capability in the actual edition and release being purchased. Retain the generated document, response, ERP result and reconciliation. Test the components together. A working local report and a working external service do not establish that their proposed connection works. Confirm monitoring, correction and support as part of the same process. Use the [procurement guide](https://erplocalization.com/guides/verify-erp-localization/) to turn the record into contract scope and the [acceptance-test guide](https://erplocalization.com/guides/erp-localization-acceptance-tests/) to verify it before go-live. ## Related on this site - [Country pages](https://erplocalization.com/countries/): key facts with sources - [E-invoicing matrix](https://erplocalization.com/e-invoicing/): country × ERP support - [All guides](https://erplocalization.com/guides/) Vendor documentation is cited only as an example of the level of evidence to ask for; it is not a recommendation or a ranking. This guide is general information, not tax or legal advice. Checked 2026-10-17. Related: [Glossary](https://erplocalization.com/glossary/) – abbreviations and terms used in these guides (SAF-T, Peppol, CTC, EN 16931, IFRS and more). --- Canonical: https://erplocalization.com/guides/erp-editions-and-compliance-dependencies/ · Last updated: 2026-10-17 · Informational only; not tax, legal or implementation advice. Featured placements are paid or promotional and do not affect the compliance data. Data: CC BY-NC 4.0 (commercial use needs a licence: https://erplocalization.com/data-licence/), attribution "ERP Localization (erplocalization.com)".