inkvoice

{
  "name": "inkvoice",
  "title": "InkVoice \u2014 XRechnung & E-Invoicing",
  "description": "German e-invoicing tools: build an XRechnung 3.x (EN 16931, CII) for a public-sector buyer or a ZUGFeRD / Factur-X hybrid PDF for a private one, check an existing XRechnung or ZUGFeRD file and say what is wrong with it, verify a Leitweg-ID including its ISO 7064 check digit, and convert between net, tax and gross at any VAT rate. Anonymous and stateless \u2014 nothing is stored. A personal access token adds the caller's own clients and invoices.",
  "version": "1.1.0",
  "documentationUrl": "https://inkvoice.net/mcp",
  "iconUrl": "https://inkvoice.net/favicon.svg",
  "url": "https://api.inkvoice.net/mcp",
  "preferredTransport": "streamable-http",
  "protocol": "mcp",
  "provider": {
    "organization": "InkVoice",
    "url": "https://inkvoice.net"
  },
  "authentication": {
    "required": false,
    "schemes": [
      "bearer"
    ],
    "description": "Anonymous access exposes the e-invoicing tools. A personal access token ('Bearer inkv_...') additionally exposes the caller's own clients and invoices.",
    "tokenUrl": "https://inkvoice.net/settings"
  },
  "defaultInputModes": [
    "application/json"
  ],
  "defaultOutputModes": [
    "application/json"
  ],
  "skills": [
    {
      "id": "calculate_vat",
      "name": "Calculate German VAT",
      "description": "Converts between net, tax and gross for a given VAT rate, in either direction.\n\nGive an amount and say whether it is net or gross, and you get all three figures back\nrounded to the cent. Germany's rates are 19 % (standard) and 7 % (reduced), but any\nrate from 0 to 100 is accepted, so this also works for an Austrian or French invoice.\n\nRounding is half-away-from-zero, the convention invoices and tax authorities use, and\nthe three returned figures always reconcile: net plus tax equals gross exactly, with\nno cent left over from rounding each separately.\n\nWhat this does NOT do: it does not decide which rate applies to a supply, handle more\nthan one rate at a time, or know anything about reverse charge, intra-community supply\nor the Kleinunternehmer rules. It is arithmetic, not tax advice."
    },
    {
      "id": "check_leitweg_id",
      "name": "Check a Leitweg-ID",
      "description": "Checks a German Leitweg-ID \u2014 the routing identifier that goes in BT-10 of an\nXRechnung to a public authority. An invoice to a German public body with a wrong or\nmissing Leitweg-ID is rejected, so this is worth checking before building a document.\n\nIt verifies the structure (Grobadressierung of 2 to 12 digits, an optional\nFeinadressierung of up to 30 alphanumerics, then two check digits) and recomputes the\nISO/IEC 7064 MOD 97-10 check digit, the same procedure an IBAN uses. When the check\ndigits are wrong it returns the ones the address parts actually imply, so the value\ncan be corrected rather than merely rejected. It also names the Bundesland the leading\ntwo digits point at, or Bund for the federation.\n\nOne real limit: the check digit is computed over the address parts with the hyphens\nremoved, which is what KoSIT specifies, so it CANNOT detect a hyphen in the wrong\nplace. '04011000-1234512345-06' and '040110001-234512345-06' both pass. That is the\nspecification's behaviour, not a defect here.\n\nWhat this does NOT do: it does not confirm that the ID belongs to a real authority or\nthat they are reachable. It checks the number, not the recipient \u2014 there is no\ndirectory lookup."
    },
    {
      "id": "create_xrechnung",
      "name": "Create an XRechnung",
      "description": "Builds a German XRechnung 3.x electronic invoice (EN 16931, CII syntax) from invoice\ndetails and returns the XML as text. This is the format German public-sector buyers\nare legally required to receive, and that many private B2B buyers now ask for.\n\nThe EN 16931 business rules are checked before anything is built, and a rejected call\ncomes back naming the rules that failed and the business term (BT-xx) each concerns.\nThe ones worth getting right up front: tax category S requires a rate above 0 %,\ncategories Z, E and AE require exactly 0 %, E and AE additionally require a stated\nexemption reason (BT-120), both parties need an email address because XRechnung\nmakes the electronic address (BT-34, BT-49) mandatory, and an IBAN (BT-84) is\nrequired, because XRechnung makes payment instructions (BG-16) mandatory (BR-DE-1).\nFor a public-sector buyer, put their Leitweg-ID in buyerReference (BT-10) \u2014\ncheck_leitweg_id will verify it first.\n\nWhat this does NOT do:\n- It does not validate against the KoSIT Pr\u00fcftool. It applies our reading of EN 16931,\n  which is not the same thing as the Schematron suite a receiving portal runs. Use\n  validate_einvoice for a second look, and the official validator before a deadline.\n- It does not produce ZUGFeRD or Factur-X. There is no PDF and no embedded XML \u2014 this\n  is a bare XML file. Use create_zugferd for the hybrid a private-sector B2B buyer\n  usually wants.\n- It handles ONE tax rate and one tax category for the whole invoice. A document\n  mixing 19 % and 7 % lines is not expressible here.\n- It does not send the invoice anywhere, and there is no Peppol.\n\nNothing is stored: no account, no invoice record, no retained personal data."
    },
    {
      "id": "create_zugferd",
      "name": "Create a ZUGFeRD / Factur-X invoice",
      "description": "Builds a ZUGFeRD 2.x / Factur-X hybrid invoice from the same details create_xrechnung\ntakes, and returns it as a PDF file.\n\nA hybrid is one invoice stated twice in one file: a PDF/A-3 document a person reads,\ncarrying the same invoice inside it as EN 16931 XML a machine books. This is the\nformat private-sector German B2B buyers generally want, where XRechnung is what public\nbodies require. If the recipient is a public authority and gave you a Leitweg-ID, you\nwant create_xrechnung instead.\n\nThe embedded XML declares plain EN 16931 \u2014 the profile ZUGFeRD calls COMFORT \u2014 not the\nXRechnung CIUS, because that CIUS is a statement about public-sector procurement.\n\nValidation is identical to create_xrechnung, except that the IBAN is optional here\n(EN 16931 makes BG-16 optional): the same EN 16931 rules are applied before anything\nis built, and a rejected call names the rules and business terms that failed.\n\nWhat this does NOT do:\n- The result is a binary PDF returned as an attachment. It is not text and there is\n  nothing useful to read in it \u2014 do not try to quote or summarise its contents. Offer\n  it to the user as a file.\n- It does not validate against veraPDF or the Mustangproject validator. The document is\n  built to be valid PDF/A-3 with the required Factur-X metadata, but that is our\n  reading rather than a validator's verdict.\n- It handles ONE tax rate and one tax category for the whole invoice, exactly as\n  create_xrechnung does.\n- It does not send the invoice anywhere, and there is no Peppol.\n- There is no logo and no custom styling. The PDF uses the default invoice layout.\n\nNothing is stored: no account, no invoice record, no retained personal data."
    },
    {
      "id": "validate_einvoice",
      "name": "Check an e-invoice",
      "description": "Reads an existing electronic invoice and reports what is wrong with it. Accepts\nXRechnung and ZUGFeRD XML in either EN 16931 syntax \u2014 CII (used by XRechnung and\nZUGFeRD) and UBL \u2014 and reports the syntax and profile it found along with the\ninvoice's key fields, so it also answers \"what is this file?\".\n\nIt checks the rules behind most real rejections: BT-10 buyer reference present, and\nits Leitweg-ID check digit when it looks like one; BT-34 and BT-49 electronic\naddresses present; tax category S not used at 0 %; BT-120 exemption reason present\nfor categories E and AE; line amounts summing to BT-106; net plus tax equalling the\nBT-112 gross; BT-115 amount due matching gross less prepaid; and the due date not\nfalling before the issue date.\n\nWhat this does NOT do:\n- It is NOT the KoSIT Pr\u00fcftool and is not a substitute for it. It covers the rules\n  that account for most rejections, not the full EN 16931 Schematron suite. A file\n  that passes here can still be rejected by a Rechnungseingangsportal.\n- It does not check the XSD schema, so a structurally invalid document may parse here.\n- It reads XML only. A ZUGFeRD PDF must have its embedded XML extracted first \u2014 pass\n  the XML, not the PDF.\n\nNothing is stored: the document is parsed in memory and discarded."
    }
  ]
}