Integrations

Use Attestwire in tools you already run

Start with a maintained integration for GitHub Actions, Medusa v2 or InvoiceShelf. Each integration is open source.

GitHub Action — attestwire/validate-einvoice-action

Check e-invoice files in your pull request before they reach a customer or access point.

- uses: attestwire/validate-einvoice-action@v1
  with:
    files: "invoices/**/*.xml"

Fatal findings fail the job. Results appear in the pull request and job summary, with optional SARIF output for the Security tab.

It runs entirely inside the runner by default. No API key, no account, no network call, nothing leaves your infrastructure. The rule engine is bundled at a pinned version, so the same commit gives the same verdict next year.

It reads what your invoices are, not what they are called: a UBL Invoice or CreditNote, a CII CrossIndustryInvoice, or a Factur-X / ZUGFeRD PDF, from which it extracts the embedded CII XML and validates that. The syntax comes from the root element, so a .xml that is not an invoice is refused by name rather than skipped.

Three details to know:

• No files means failure. A bad file pattern cannot produce a misleading green build.
• Inputs are checked first. Unknown settings fail with a list of accepted values.
• Annotations use document paths. They do not invent a source line that the rule engine cannot identify reliably.

Supplying api-key switches it to the hosted API instead, which is what you want if you also need a shareable validation record.

MIT. The full README, including api mode and every exit code → · What it means for a release pipeline →

Medusa v2 — medusa-plugin-einvoice

When an order is placed, generate XRechnung, Peppol BIS 3.0 or Factur-X (CII) XML XML from the order, validate it before storage, and attach the result to the order.

Generation and validation run locally and for free via @attestwire/en16931. There is no API to sign up for, no per-invoice cost, and no network call in the default configuration. The seller identity, payment instructions and payment terms are plugin options, because the German CIUS requires all three — BR-DE-1 wants payment instructions, BR-DE-2/5/6/7 want a seller contact — so the first document you generate is not also your first rejection.

npm install medusa-plugin-einvoice

The plugin →

InvoiceShelf — the EInvoice module

Turns an InvoiceShelf invoice into a standards-conformant electronic invoice: EN 16931, plus the national layer the customer's country implies — XRechnung for Germany, Factur-X for France, plain EN 16931 for everything else, all overridable. It is validation-first: before any XML is offered, the invoice is checked and you get findings with official rule ids, a plain-English explanation, a suggested fix and a link. If the invoice fails, there is no download button.

It is built and maintained by Attestwire, and it calls the Attestwire API to do its work. We have a direct commercial interest in you installing it, and its own README opens with the same disclosure. The module is AGPL-3.0-only, and the mapping — the part that decides what your invoice data means in EN 16931 terms — is entirely in that repository, in PHP, unit-tested, and readable without running anything.

The module, and its "Honest scope" section →

What none of them do

These integrations build and check documents; they do not transmit them. Read the exact scope. Building something else? say what you are wiring up.