{"audit":{"version":"1.5","generated_at":"2026-09-25T22:08:57.208395+00:00","generated_by":"Agenstry","report_url":"https://agenstry.com/agents/api.inkvoice.net","methodology_url":"https://agenstry.com/methodology","verifier_jwks_url":"https://agenstry.com/.well-known/jwks.json","subject":{"domain":"api.inkvoice.net","name":"inkvoice","url":"https://api.inkvoice.net/.well-known/agent-card.json"}},"identity":{"provider":{"organization":"InkVoice","url":"https://inkvoice.net"},"registry_verification":null,"signature":{"signed":false,"signature_valid":null}},"protocol":{"version":null,"supports_streaming":false,"supports_push_notifications":false},"operational":{"live_state":"no_url","live_responds":null,"last_status_code":200,"last_elapsed_ms":23,"last_error":null},"track_record":{"first_seen":"2026-09-25T19:31:15.857035+00:00","last_checked":"2026-09-25T19:31:15.857035+00:00","last_seen_ok":"2026-09-25T19:31:15.857035+00:00","checks_total":1,"checks_ok":1,"uptime_pct":100.0,"uptime_window_days":30,"uptime_probes":1,"archived":false,"archived_reason":null},"conformance":{"score":31,"grade":"F","summary":"F-grade: card is reachable but fails most operational signals.","criteria":[{"key":"valid_card","label":"Valid AgentCard","points":10,"max_points":10,"status":"pass","detail":"Parseable AgentCard returned by the well-known endpoint (Agenstry readiness signal; not an official TCK certification)."},{"key":"live_responds","label":"Live JSON-RPC","points":2,"max_points":25,"status":"fail","detail":"Card is valid but has no .url field."},{"key":"protocol_version","label":"Protocol version","points":0,"max_points":10,"status":"fail","detail":"No protocolVersion in card."},{"key":"signature","label":"JWS signature","points":0,"max_points":10,"status":"info","detail":"Card is unsigned (most published agents are)."},{"key":"uptime","label":"Uptime track record","points":0,"max_points":15,"status":"info","detail":"Only 1 probe so far, need ≥5 for an uptime grade."},{"key":"skills","label":"Skill declaration","points":10,"max_points":10,"status":"pass","detail":"Declares 5 skills with structured metadata. 5 skills without tags — optional in 0.x, REQUIRED once you move the card to v1.0."},{"key":"verified_identity","label":"Verified Identity","points":5,"max_points":10,"status":"partial","detail":"Provider declared: InkVoice (https://inkvoice.net). Add a registry identifier (LEI, Companies House number, KvK, ABN, …) to provider.legalEntity for full verified-business credit."},{"key":"freshness","label":"Freshness + modern flags","points":4,"max_points":5,"status":"pass","detail":"seen in upstream source within 0d"},{"key":"security","label":"Security declaration","points":0,"max_points":5,"status":"info","detail":"Neither securitySchemes nor securityRequirements declared — how to authenticate is unstated."}]},"card_read":{"findings":[],"clean":true,"source_url":"https://api.inkvoice.net/.well-known/agent-card.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.","tags":[],"examples":[],"inputModes":[],"outputModes":[]},{"id":"check_leitweg_id","name":"Check a Leitweg-ID","description":"Checks a German Leitweg-ID — 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 — there is no\ndirectory lookup.","tags":[],"examples":[],"inputModes":[],"outputModes":[]},{"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), and both parties need an email address because XRechnung\nmakes the electronic address (BT-34, BT-49) mandatory. For a public-sector buyer, put\ntheir Leitweg-ID in buyerReference (BT-10) — check_leitweg_id will verify it first.\n\nWhat this does NOT do:\n- It does not validate against the KoSIT Prüftool. 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 — 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.","tags":[],"examples":[],"inputModes":[],"outputModes":[]},{"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 — the profile ZUGFeRD calls COMFORT — not the\nXRechnung CIUS, because that CIUS is a statement about public-sector procurement.\n\nValidation is identical to create_xrechnung: the same EN 16931 rules are applied before\nanything is 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 — 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.","tags":[],"examples":[],"inputModes":[],"outputModes":[]},{"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 — CII (used by XRechnung and\nZUGFeRD) and UBL — 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üftool 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 — pass\n  the XML, not the PDF.\n\nNothing is stored: the document is parsed in memory and discarded.","tags":[],"examples":[],"inputModes":[],"outputModes":[]}],"provenance":[{"source":"manifests","first_seen":"2026-09-25T19:31:15.857035+00:00"}],"recent_probes":[{"fetched_at":"2026-09-25T19:31:15.857035+00:00","ok":true,"status_code":200,"error":null,"elapsed_ms":23,"live_responds":null}],"catalog_attestation":null,"operator_revenue_evidence":{"evidence_class":"operator_submitted","authenticity":{"rung":"no_operator_evidence","rank":0,"why":"No verifiable operator evidence has been submitted for this agent.","thresholds":{"min_independent_payers":3,"min_verified_usd":25.0},"engine_table":"agent_authenticity","merge_rule":"max(existing_rank, rank)"},"metric_metadata":{"provenance":"operator_submitted_evidence","confidence":"attested","coverage":{"numerator":0},"as_of":"2026-09-25T22:08:57.215081+00:00","definition":"Revenue proofs submitted by the verified owner and re-checked by Agenstry against the settlement chain or the operator's own Stripe account. Only independently confirmed proofs are counted."},"counts":{"retained":0,"verified":0,"unverifiable":0},"verified":{"gross_usd":0.0,"transactions":0,"independent_payers":0},"detail_url":"https://agenstry.com/api/agents/api.inkvoice.net/evidence","dispute_url":"https://agenstry.com/agents/api.inkvoice.net/dispute"},"verification_history":[]}