api

A unified API for compliant e-invoicing across countries

Use the same API structure, the same data model, and the same integration logic across countries, while DDD handles local invoicing, tax, and reporting complexity in the background.

Our actual API payload object, maximally standardized across all countries.
Loading data…

Convert standardised .JSON payload into local .XML and reports to tax portals

flag
DE

How to

From one API connection to compliant invoice flows

01 Set up one API model

Map your invoice flows once and connect through one standardized API model.

Send standardized invoice data through one API

02 Send standardized data

Use the same core data model and same steps across countries.

Receive compliant invoice documents back from DDD

03 Receive compliant output

Get back the required invoices, documents, or links through the same connected model

Expand into new countries and clients without rebuilding your integration

04 Expand without rebuilding

Add countries, flows, and end-clients without changing your core integration.

What unified API really means in practice

We have abstracted and standartized the input in DDD to the maximum degree. You keep one connection across the countries, while we transform your invoice data into the local formats, required for each market. This way you never deal with local XMLs.

  • Same API structure across countries
  • Same core payload logic across invoice flows
  • Local formats, tax logic, and reporting handled by DDD
  • Return requested documents through the same model
What unified API really means in practice

Cover every invoice type without rebuilding the logic

All invoice documents can run through the same API structure, without becoming separate integration projects.

Basic invoicesStorno invoicesCorrective invoicesPro-forma invoices
Advance invoicesCredit notesSelf-invoices
B2C, B2B, and B2G invoice flows through one API

Support B2C, B2B, and B2G flows

The same unified API can route consumer, business, and government invoice flows through the right local compliance path, without separate integrations for each buyer type.

  • Consumer, business, and government invoice flows
  • One API model across buyer types
  • Local routing handled behind the API
  • Expand flows without rebuilding your integration

Generate e-invoices, fiscalize, and send compliant PDFs

DDD takes your standardized invoice data and converts it into the required local outputs, from structured e-invoice formats to fiscalization proof data, compliant PDFs, and tax authority submissions where required.

  • Generate local e-invoice formats
  • Create compliant PDFs with required proof data
  • Support fiscalization and QR-code requirements
  • Submit or prepare data for local tax authority flows
Generate e-invoices, fiscalize, and send compliant PDFs

Standardization for both outgoing and incoming invoices

One structure for every invoice direction, document type, and local requirement.

Issued invoices

  • Create e-invoices
  • Create localized PDFs
  • Distribute invoices through supported channels
  • Get requested invoice documents back as links or files

Received invoices

  • Standardize received invoices in one structure data format
  • Keep the same API logic across markets
  • Route invoice data into internal workflows
  • Retrieve structured invoice outputs consistently
Start free integration
Add a new country without changing the integration model

Add a new country without changing the integration model

With DDD, adding a new country does not mean rebuilding invoicing compliance from scratch. You simply onboard a new legal entity / client, and start using the service.

  • Same API structure when adding countries
  • Same connection model across markets
  • Faster rollout into new countries
  • Less engineering overhead during expansion

Reuse the same API across end-clients

Software providers can reuse the same API model across multiple customer environments. Each end-client gets a separate authentication code, company setup, and country configuration, while your product keeps one integration pattern.

  • Same API model across multiple end-clients
  • Separate authentication per client setup
  • Easier multi-client rollout
  • Supporting APIs for customer setup, invoice data, and document retrieval
Reuse the same API across end-clients
Local tax logic is built into the layer

Local tax logic is built into the layer

DDD helps handle local invoicing requirements behind the API layer, including VAT rates, tax codes, exemption logic, and local compliance rules where supported.

  • Built-in local VAT rates
  • Exemption rules and exemption clauses included
  • Local VAT code mapping
  • Compliance logic handled inside the API layer

99% of government changes handled automatically

DDD keeps your invoicing flow aligned with changing tax authority requirements, so your team does not need to rebuild country-specific logic every time formats, validations, or reporting rules change.

  • Format and validation updates handled by DDD
  • Reporting rule changes maintained centrally
  • Less country-specific logic to maintain in your system
  • Fewer compliance updates for your development team
99% of government changes handled automatically
Built to support higher invoice volumes with mass API

Built to support higher invoice volumes with mass API

DDD helps you process larger volumes of invoices with a mass API, that handles thousands of invoice objects in one "object of objects".

  • High-volume invoice processing
  • Support for bulk invoice flows (e.g. utility, telecom, SaaS providers...)
  • Thousands of invoices, one API request
  • Alternatively: file preparation, processing, notification and download

Integrate once, expand across countries through one API

Use one API structure across invoice flows, countries, and customer setups, while DDD handles local formats, tax logic, fiscalization, and reporting requirements in the background.

Discuss your API use case

USE CASE

This is how it's done.

Logitude customer story on using DDD Invoices unified API

FAQ

Frequently asked questions

The DDD API connects your software to DDD's invoicing compliance infrastructure. Your system sends invoice data to DDD through one API. DDD then processes that data according to the relevant local requirements, such as e-invoicing formats, fiscalization rules, tax authority reporting, compliant PDFs, XML files, QR codes, invoice delivery and archiving, depending on the country and use case. This means your team can keep your existing invoice generation logic, while DDD handles the local compliance layer behind it.
No. The main benefit of the DDD API is that your team does not need to build and maintain separate local integrations for every country, tax portal, e-invoicing network or invoice format. You integrate with DDD once, then DDD handles the country-specific compliance requirements behind the scenes, where supported. This helps reduce engineering work, maintenance and rollout time when you need to support new markets.
You send the invoice data required to create and process a compliant invoice, such as company details, customer details, invoice items, tax data, totals, dates, payment information and country-specific fields where needed. The exact required data depends on the country, invoice type and compliance flow. DDD validates the data and helps identify missing or incorrect information before the invoice is processed.
Depending on the country and workflow, DDD can return invoice status, validation results, generated invoice files, compliant PDFs, XML files, QR codes, fiscalization proof, tax authority responses, delivery status and invoice history. The goal is not only to submit the invoice, but to give your system visibility into what happened after the invoice entered the compliance flow.
Yes. DDD is designed to work behind your existing invoice flow. Your software can continue creating invoices in the way it already does. DDD then acts as the compliance layer that transforms, validates and processes the invoice according to local requirements. This is especially useful if you already have billing, checkout, ERP, POS or subscription logic in place and do not want to rebuild your core invoice process for every market.
Yes. You can test the API before switching to production. This lets your team validate the invoice flow, check required data, test country-specific rules and confirm that the expected invoice output is generated before real invoices are sent to customers or tax authorities. Testing helps reduce production risk and makes the go-live process more predictable.
If an invoice fails, DDD provides status information and error details so your team can understand what needs to be fixed. Failures are usually connected to missing data, incorrect tax settings, invalid customer information, unsupported invoice structures, workflow configuration issues or country-specific requirements. The goal is to make errors visible and actionable, so your team can fix the issue without guessing where the problem happened.
Yes. DDD can support more than invoice submission through the API. For software providers and platforms, the API can also be used for customer provisioning, company setup, invoice data, authentication credentials and operational control, depending on the implementation. This is useful if you need to onboard multiple end-clients, legal entities or markets through your own software.
Yes. The API and dashboard can work together. Your software can send and manage invoice data through the API, while your team uses the DDD dashboard to monitor invoice statuses, review history, inspect errors, manage companies or support operational workflows. This gives developers API control while finance, support or operations teams still get visibility through the dashboard.
The API is best suited for software providers, platforms, ERPs, billing systems, e-commerce systems, POS providers and companies that want to embed invoicing compliance directly into their own product or internal system. It is the right path when you want a scalable, flexible integration that can support multiple countries, customers, legal entities or invoice flows over time.