InkVoice - XRechnung & E-Invoicing

German e-invoicing, as MCP tools. Build a valid XRechnung 3.x (EN 16931, CII syntax) from invoice details, check an existing XRechnung or ZUGFeRD file and get back what is actually wrong with it, verify a Leitweg-ID down to its ISO 7064 check digit, and convert between net, tax and gross at any VAT rate. Everything here is anonymous, stateless and free. No account, no API key, nothing stored. A personal access token from an InkVoice account adds that account's own clients and invoices to the same URL. Also exposes a knowledge resource covering the German mandate timeline (receiving since 2025, issuing from 2027/2028), the § 14 UStG mandatory invoice fields, the § 33 UStDV small-amount threshold, how § 19 UStG Kleinunternehmer are treated, and which ZUGFeRD profiles do not qualify as an e-invoice at all. Maintained by InkVoice, which runs the same generator in production. Its output is checked against the official KoSIT Prüftool in CI.

该来源不提供完整文件导出（国内平台多为平台内托管），仅存元数据与原链

接入信息

传输形态: http
鉴权方式: 鉴权未知
端点: https://inkvoice--dev-mh.run.tools

鉴权方式未标注，请核对官方文档后再接入——不要直接使用以下片段

{
  "mcpServers": {
    "InkVoice - XRechnung \u0026 E-Invoicing": {
      "url": "https://inkvoice--dev-mh.run.tools"
    }
  }
}

能力清单

工具	说明
calculate_vat	Converts between net, tax and gross for a given VAT rate, in either direction. Give an amount and say whether it is net or gross, and you get all three figures back rounded to the cent. Germany's rates are 19 % (standard) and 7 % (reduced), but any rate from 0 to 100 is accepted, so this also works for an Austrian or French invoice. Rounding is half-away-from-zero, the convention invoices and tax authorities use, and the three returned figures always reconcile: net plus tax equals gross exactly, with no cent left over from rounding each separately. What this does NOT do: it does not decide which rate applies to a supply, handle more than one rate at a time, or know anything about reverse charge, intra-community supply or the Kleinunternehmer rules. It is arithmetic, not tax advice.
create_xrechnung	Builds a German XRechnung 3.x electronic invoice (EN 16931, CII syntax) from invoice details and returns the XML as text. This is the format German public-sector buyers are legally required to receive, and that many private B2B buyers now ask for. The EN 16931 business rules are checked before anything is built, and a rejected call comes back naming the rules that failed and the business term (BT-xx) each concerns. The ones worth getting right up front: tax category S requires a rate above 0 %, categories Z, E and AE require exactly 0 %, E and AE additionally require a stated exemption reason (BT-120), and both parties need an email address because XRechnung makes the electronic address (BT-34, BT-49) mandatory. For a public-sector buyer, put their Leitweg-ID in buyerReference (BT-10) — check_leitweg_id will verify it first. What this does NOT do: - It does not validate against the KoSIT Prüftool. It applies our reading of EN 16931, which is not the same thing as the Schematron suite a receiving portal runs. Use validate_einvoice for a second look, and the official validator before a deadline. - It does not produce ZUGFeRD or Factur-X. There is no PDF and no embedded XML — this is a bare XML file. - It handles ONE tax rate and one tax category for the whole invoice. A document mixing 19 % and 7 % lines is not expressible here. - It does not send the invoice anywhere, and there is no Peppol. Nothing is stored: no account, no invoice record, no retained personal data.
check_leitweg_id	Checks a German Leitweg-ID — the routing identifier that goes in BT-10 of an XRechnung to a public authority. An invoice to a German public body with a wrong or missing Leitweg-ID is rejected, so this is worth checking before building a document. It verifies the structure (Grobadressierung of 2 to 12 digits, an optional Feinadressierung of up to 30 alphanumerics, then two check digits) and recomputes the ISO/IEC 7064 MOD 97-10 check digit, the same procedure an IBAN uses. When the check digits are wrong it returns the ones the address parts actually imply, so the value can be corrected rather than merely rejected. It also names the Bundesland the leading two digits point at, or Bund for the federation. One real limit: the check digit is computed over the address parts with the hyphens removed, which is what KoSIT specifies, so it CANNOT detect a hyphen in the wrong place. '04011000-1234512345-06' and '040110001-234512345-06' both pass. That is the specification's behaviour, not a defect here. What this does NOT do: it does not confirm that the ID belongs to a real authority or that they are reachable. It checks the number, not the recipient — there is no directory lookup.
validate_einvoice	Reads an existing electronic invoice and reports what is wrong with it. Accepts XRechnung and ZUGFeRD XML in either EN 16931 syntax — CII (used by XRechnung and ZUGFeRD) and UBL — and reports the syntax and profile it found along with the invoice's key fields, so it also answers "what is this file?". It checks the rules behind most real rejections: BT-10 buyer reference present, and its Leitweg-ID check digit when it looks like one; BT-34 and BT-49 electronic addresses present; tax category S not used at 0 %; BT-120 exemption reason present for categories E and AE; line amounts summing to BT-106; net plus tax equalling the BT-112 gross; BT-115 amount due matching gross less prepaid; and the due date not falling before the issue date. What this does NOT do: - It is NOT the KoSIT Prüftool and is not a substitute for it. It covers the rules that account for most rejections, not the full EN 16931 Schematron suite. A file that passes here can still be rejected by a Rechnungseingangsportal. - It does not check the XSD schema, so a structurally invalid document may parse here. - It reads XML only. A ZUGFeRD PDF must have its embedded XML extracted first — pass the XML, not the PDF. Nothing is stored: the document is parsed in memory and discarded.

纠错与举报（发现条目失效、署名有误或涉及侵权？）

提交举报 / 纠错

侵权举报经核验成立后，我们会即时下线该条目并删除已存的内容副本。