Most accounting software picks one country and treats everything else as an afterthought. Vedron’s accounting is set up the other way: the chart of accounts, the e-invoicing format and the tax rules are resolved per company from a lookup, not hardcoded.
Four standards are live today. Three more are registered and in progress. The rest of this post is honest about which is which.
Chart of accounts — a lookup, not a fork
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 is what lets two companies on the same platform run different national standards side by side, without either one’s logic leaking into the other.
Four standards are fully mapped and live today: SKR03 (Germany), UOR (Poland), SG_FRS (Singapore) and CZ_GAAP (Czech Republic). Three more — SKR04, UK GAAP and IFRS — are registered in the same lookup and in progress. Adding the next one is registry work, not a rebuild.
E-invoicing — one dispatcher, per-country handlers
One 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 handler that shares common line-item, tax and formatting logic.
Live today: Germany’s XRechnung, Poland’s KSeF, Italy’s FatturaPA, and generic EN 16931 via Peppol.
Tax rules — data-driven per company, not unified yet
Which VAT rate or code applies to a given transaction is resolved by priority order, from company and tenant data, not from hardcoded logic that would need a code change to adjust. Being direct: Germany’s tax-rule table and Poland’s tax schema are currently two separate country-specific structures, not one unified cross-country engine. Both are real and in use. Merging them is on the roadmap.
What ties it together — period locks and verified reconciliation
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 company — not a UI warning that can be clicked past.
The ledger has also been reconciled, not just assumed. A multi-phase check confirmed zero discrepancy across all 241 posted accounts after each reconciliation step.
Where DATEV fits
Most German tax accountants work in DATEV. It is the tool their workflow assumes. DATEV expects a specific structure: a chart of accounts on SKR03 or SKR04, postings formatted to DATEV’s import spec, documents organised so DATEV’s document side can link them back to postings.
Vedron’s chart of accounts sits directly on SKR03 (with SKR04 in progress), so postings are already in DATEV’s expected structure. Every invoice and receipt — including the ones captured by OCR — is reconciled against the ERP’s own vendor and tax-rule data before being treated as final.
Common questions
Does this mean every accounting standard is supported today? No. Four are live (SKR03, UOR, SG_FRS, CZ_GAAP). Three more are registered and in progress (SKR04, UK GAAP, IFRS).
Is the tax-rule engine unified across countries? Not yet. Germany and Poland currently have separate country-specific tax-rule schemas, both real and data-driven. Merging them is on the roadmap.
Does this replace my tax accountant? No. It removes the reformatting and re-entry work so what reaches your accountant is already structured for their software.
What if my company operates in a country without a fully mapped standard yet? You can still use the platform’s tenant and company-default fallback, and a dedicated mapping can be added without restructuring your data. Worth a direct conversation about your country.
Talk to us about your setup
Book a short call. Beta clients get two months of custom setup on us.