EU e-invoices from the billing data you already have

1. 1You give it an invoiceOne invoice as you already have it: a PDF, a Stripe invoice, a spreadsheet export or a CII e-invoice. For a PDF, every number the AI reads is checked against the PDF with no AI.
2. 2An AI writes a converterThe AI writes a small program, map.py, that turns that kind of invoice into a Peppol e-invoice.
3. 3It runs locked, and fixes itselfThe program runs in a locked CreateOS sandbox with no internet. The official EU checker lists every error; the AI reads them and fixes its own code, up to 8 tries.
4. 4Released only if 3 checks passThe EU rules, the totals and the company IDs. If any check fails, nothing is released, and the page says exactly why.

• Follows the official EU e-invoice rulesThe CEN EN16931 rules and the Peppol BIS Billing 3.0 rules, run by the official checker inside the sandbox.
• The totals match the original billLines, net total, VAT per rate and amount due must equal what the customer was actually billed. No AI is involved in this check.
• Every company ID comes from the original invoiceEvery company name, VAT number, Peppol ID and bank account must appear in the original invoice or the declared settings. Nothing invented. No AI is involved in this check.

• The e-invoiceThe Peppol XML file, ready for your Peppol access point.
• A certificateWhich rules ran (with their versions and file hashes), the totals compared, the IDs traced, and which AI and sandbox were used.
• A reusable converterThe approved converter turns the next invoice of the same kind in about 1.7 seconds, with no AI call.

• Trying to fool the checks. We planted three converter bugs into an approved e-invoice: amounts in cents treated as euros, a dropped discount, and an invented buyer Peppol ID with a valid checksum. Each one passes every official rule, and each one is held back by the totals check or the ID check. The home page runs these live.
• Converting with the AI off. The approved converters ran on a second Stripe test invoice and a second spreadsheet export. Both were approved in about 1.7 s with 0 AI calls.
• Honest limits of the evidence. Across our 47 test runs, all 35 e-invoices that passed the official rules also matched their original, so the extra checks never caught a real AI slip; the planted bugs are the evidence that they would. Results vary from run to run: Stripe invoices reached approval in 13 of 14 runs, CSV exports in 6 of 6, PDFs in 6 of 6, and the hard official CEN example in 13 of 24 (most misses came before we improved the AI's feedback). Nothing was ever released without all three checks passing.

An invoice doesn't always carry everything a Peppol e-invoice needs, such as the Peppol IDs of seller and buyer. Those values come from declared settings for each format, and the ID check accepts them alongside the invoice itself. All of them are fictional, in valid formats.

• CreateOS Sandbox: the locked VM where the AI's code and the EU checker run, with the network off.
• Stripe Projects: set up the whole stack from the Stripe CLI, including the AI model's key.
• Qwen3-Coder 480B, through Featherless: the AI that writes and fixes the converter.
• Vercel and Next.js: host and build this site.

• Passing the CEN and Peppol rules is not delivery over the Peppol network, which needs an access point.
• The sample invoices are labelled in the app: one official CEN example (unmodified), Stripe test-mode invoices we created, and CSV rows we wrote. Seller and buyer IDs are fictional; the CEN example's seller contact is our declared setting, because the example leaves it empty and Peppol's German rules require one.
• Live runs are limited to one at a time and 60 a day, so the public site can't run up the AI bill.