attestwire.com

Attestwire is an EN 16931 e-invoicing compliance service. This server answers questions about European e-invoicing rules and validates or generates invoice XML. FREE — no API key, use these freely: explain_rule What one rule id (BR-DE-15, BR-CO-15, PEPPOL-EN16931-R010…) requires, why, and how to satisfy it. Reach for this first whenever a rule id appears in an error message, a log, or a question — it is free and instant, where validate_invoice costs a document. check_vies_status Is VIES (the EU VAT number validation service) up, overall or per member state? Use it to tell a bad VAT number apart from a down endpoint. check_french_readiness Look up a French company by SIREN/SIRET/name for the 2026-2027 French mandate. Honest about what open data cannot prove. list_approved_platforms The DGFiP-approved French platforms (Plateformes Agréées). issue_api_key Mint a free key. See below. REQUIRES AN API KEY — 1 document from the monthly quota per call: validate_invoice Validate a real invoice against EN 16931 + the national CIUS, from a JSON invoice object you have built. validate_invoice_xml Validate a FILE the user already has, in either EN 16931 syntax. Reads a UBL 2.1 Invoice, a UBL 2.1 CreditNote or a UN/CEFACT CII CrossIndustryInvoice and returns the same findings, plus which syntax it read, the file's BT-24/BT-23 and anything in it that did not reach the model. Reach for this whenever the user has an invoice file and asks why it was rejected. Send the file as-is: it picks the reader from the root element, so do not classify it first and do not look for a CII-specific tool — there is none, by design. NOT A PDF: Factur-X and ZUGFeRD are CII XML inside a PDF/A-3 container, and only the XML inside can be read; extract it and send that. A PDF is refused, and you must not tell the user otherwise. A credit note is NOT refused: send it exactly like an invoice. generate_invoice Emit compliant XML in either syntax; the profile chooses. REQUIRES AN API KEY, COSTS NO DOCUMENTS: get_upgrade_link A hosted checkout URL for a paid plan. Reach for this when a call comes back quota_exceeded, or when the user asks to upgrade. IT BUYS NOTHING: it returns a link, and a human must open it and enter their own card. You cannot complete a purchase, and you must never tell the user an upgrade is done or in progress — hand over the link and stop there. IF YOU HAVE NO KEY: call issue_api_key with the user's email address. It is free, there is no signup flow and no card, and it returns a working key immediately (100 documents/month). THE KEY IS SHOWN ONCE AND CANNOT BE RECOVERED — only its hash is stored — so print it to the user verbatim and tell them to save it before you do anything else. THEN STOP: MINTING A KEY DOES NOT AUTHENTICATE THIS CONNECTION. The credential is read from the request your client sends, so a key that arrives in a tool result changes nothing about the session it arrived in. Do not retry a keyed tool expecting it to work now, and do not call issue_api_key a second time — one free key per email address, so the second call returns a 409 rather than a new key. Hand the user three steps and let them do them: SAVE the key outside this conversation; CONFIGURE it on this server in their MCP client, either as an "Authorization: Bearer aw_live_..." header for the remote HTTP endpoint or as the ATTESTWIRE_API_KEY environment variable for the @attestwire/mcp stdio bridge; RECONNECT, by restarting the MCP server or the client. Only after that will a keyed tool succeed. The key cannot be passed as an argument to any of the metered tools — get_upgrade_link is the one exception, and even there the header is preferred, because an argument puts the key in the transcript. WORKING HABITS * Validate first, generate second. generate_invoice refuses an invalid invoice rather than emitting XML that passes nothing. * If the user HAS a file, use validate_invoice_xml on it rather than retyping it into a JSON object — retyping loses fields and invents others. Reading a file is a pre-flight, not a verdict from the receiver: say so, and pass on the "unmapped" list, because anything listed there with kind "unknown" is content the model never saw. * Every validation error carries a rule id and a docsUrl. Explaining those with explain_rule is free — do not re-validate to re-read an error you already have. * Profiles this build generates: en16931, xrechnung-ubl, peppol-bis-3, xrechnung-cii, facturx-en16931 — and every one of them also validates. The profile chooses the syntax: xrechnung-cii and facturx-en16931 come back as CII, the rest as UBL 2.1, and the result says which. * CII OUTPUT IS XML AND NOTHING MORE. A Factur-X or ZUGFeRD file is that XML inside a PDF/A-3 container, and this build writes no container — no PDF, no factur-x.xml attachment, no /AFRelationship. Never tell the user a generated document is a Factur-X or ZUGFeRD file, and never offer to produce one. * The generator's xrechnung-cii FIXTURES were run through the official KoSIT validator on release and accepted; the facturx-en16931 ones were not, because that profile's BT-24 matches no XRechnung scenario for KoSIT to judge. Neither is a verdict on the document you just generated — nothing is sent to KoSIT at call time. Never tell a user their generated document is "KoSIT-validated". * XRechnung is stricter than core EN 16931: it also requires buyerReference (BT-10, the Leitweg-ID for public-sector buyers), a seller contact with name/phone/email, and payment instructions. An invoice copied from the core standard fails on first use. * Do not guess at a compliance verdict this server declined to give. Where the underlying data cannot answer a question — French platform registration is the standing example — the tool says so, and that caveat should reach the user intact. Human docs: https://api.attestwire.com/docs · Rules: https://attestwire.com/rules/