Most accounting software picks one country's rules and treats everything else as an afterthought -- or doesn't handle it at all. Vedron's accounting engine was built the other way around: chart of accounts, e-invoicing formats, and tax rules are all resolved per company from a registry, not hardcoded to a single market. DATEV/SKR03 support for Germany is one live, proven piece of that -- not the whole pitch.
Chart of accounts: a registry, not a fork
Instead of hardcoding one chart-of-accounts structure per deployment, every posting resolves its account through a three-tier lookup: a company-specific override first, then a tenant default, then a code-level standard definition -- keyed by tenant, company, and account. That's what lets two companies on the same platform run genuinely different national standards side by side, with neither one's chart of accounts leaking into the other's postings.
Today four standards are fully mapped and live -- SKR03 (Germany), UOR (Poland), SG_FRS (Singapore), and CZ_GAAP (Czech Republic) -- with three more (SKR04, UK GAAP, IFRS) already registered in the same structure and in progress. That's the honest state: a real, working multi-standard registry, not yet "every country," but built so adding the next one is registry work, not a rearchitecture.
E-invoicing: one dispatcher, per-country adapters
The same pattern holds for e-invoicing. A single dispatcher resolves which structured format a given invoice needs based on the seller's country and whether the buyer is a government entity, then hands off to a format-specific module that shares a common core -- line-item handling, tax-category mapping, formatting -- rather than duplicating that logic per country. Live today: Germany's XRechnung, Romania's e-Factura, Italy's FatturaPA, France's Factur-X, Spain's Facturae, and a generic Peppol BIS path for other EU B2G cases. Poland's KSeF gets its own deeper integration beyond a format adapter, since it's a live government submission API with its own auth/session/polling workflow, not just an XML shape.
Tax rules: data-driven per company, honestly not fully unified yet
Tax rule resolution -- which VAT rate or code applies to a given transaction -- is priority-ordered and data-driven per company and tenant, not hardcoded logic that would need a code change to adjust. Being direct about where we are: Germany's tax-rule table and Poland's tax schema are currently two separate, country-specific structures rather than one unified cross-country tax engine. Both are real and both are data-driven, but they haven't been merged into a single abstraction yet -- that's accurate scope, not a finished universal tax engine.
What ties it together: period locking and verified reconciliation
None of this matters if the underlying ledger can drift. Closed periods are enforced at the database level -- a trigger blocks edits to manual journal entries once a fiscal period is marked closed, for that specific company, not just a UI warning that can be clicked past. And it's been verified, not just assumed: a multi-phase reconciliation project confirmed zero discrepancy across all 241 account entries spanning 2021-2024 on a real customer's books after certified-balance corrections -- the kind of check most systems never run, let alone pass.
Where DATEV fits into this
Most German tax accountants work in DATEV -- it's the standard their entire workflow assumes. DATEV expects a specific structure: a chart of accounts following SKR03 or SKR04, postings formatted to DATEV's own import spec (account number, counter-account, amount, date, document reference), and documents organized so DATEV's own document-management side can link them back to postings. A generic export -- a plain CSV, a PDF summary -- doesn't satisfy this even with correct numbers, because DATEV's import reads for exact structure, not meaning.
Vedron's chart of accounts sits directly on SKR03 (with SKR04 in progress), so postings are already in DATEV's expected structure without remapping at export time. Every invoice and receipt -- including ones captured via OCR -- is reconciled against the ERP's own vendor and tax-rule data before being treated as final, so a misread OCR amount or VAT rate gets corrected rather than silently exported as fact. Postings carry their document references through to export, so DATEV can link a booking back to the actual invoice it came from.
Frequently asked questions
Does this mean every accounting standard is supported today?
No -- four are fully live (SKR03, UOR, SG_FRS, CZ_GAAP), three more are registered and in progress (SKR04, UK GAAP, IFRS). The architecture supports adding standards without a rearchitecture, but "architected for" and "already built" are two different claims, and we're being specific about which is which.
Is the tax-rule engine unified across countries yet?
Not yet -- Germany and Poland currently have separate, country-specific tax-rule schemas, both real and data-driven, but not merged into one cross-country model. That's on the roadmap, not done today.
Does this replace my tax accountant?
No -- whether the output is a DATEV import or another country's format, this removes the manual reformatting/re-entry work so what reaches your accountant is already correctly structured, letting them focus on review rather than data wrangling.
What happens if my company operates in a country without a fully mapped standard yet?
You can still use the platform's tenant/company-default fallback in the same registry, and a dedicated mapping can be added without restructuring how your data is stored -- worth a direct conversation about your specific country's requirements.
Have a question specific to your setup?
Every seller's marketplace mix and stock setup is a little different -- if you're weighing this against your own, book a short call and we'll walk through it with you directly rather than leaving you to figure it out from a blog post alone.
Beta offer: if you join as a beta client, custom integration setup -- configured for your actual marketplace and inventory mix -- is free for your first 2 months.
Still evaluating and need more time than the standard trial window? Just ask us for an extension -- we're happy to give you the room to actually test it properly before deciding.