com.yaktool/invoice

Check an invoice you are ABOUT TO ISSUE, passed as structured fields, against 25 documented rules. The complement of check_invoice_fields: that one parses an existing invoice from text, this one takes the draft your agent is building — and because the amounts are computed here (per VAT rate, as Article 226 requires), the arithmetic rules cannot fail by construction. THREE DOCUMENT TYPES: "vat" applies the EU VAT Directive Article 226 particulars (INV-001…016); "commercial" and "proforma" apply customs practice instead (CINV-002…010: HS code and origin per line, Incoterms, net weight, EORI when goods cross the EU border) — a proforma result also reminds you it must be visibly marked, since it is not a VAT invoice. THE SCENARIO IS INFERRED, NOT ASKED: from each party's country (explicit field, or the VAT prefix with EL→GR handled) the tool derives domestic/intra-EU/export and B2B/B2C, and only then decides which particulars are required — e.g. the customer VAT number only on an intra-EU B2B supply, an exemption wording whenever any line is zero-rated. FORWARDED CHECKS KEEP THEIR HOME RULE IDS: VAT numbers (INV-015/016 with 28-country check digits), EORI (EORI-*), IBAN (IBAN-*), RF creditor references (RF-*), HS codes (HS-*, per line), Incoterms 2020 (INC-*). Line-level problems come back in lineIssues[] with a 0-based line index so you can point at the exact line. Not covered, stated rather than hidden: VAT rate correctness per country (no rate tables — you supply the rate, it does the arithmetic), currency conversion, national add-ons beyond the directive, and this is not tax advice. Returns { scenario, computed{lines[{lineNet}], rateGroups[{rate,taxable,vat}], totals{net,vat,gross,weightKg?}}, findings[], lineIssues[{line, findings[]}], particulars[{id,label,status,detail?}], readyToIssue }.

Check a plain invoice — paper, PDF, or one not yet turned into an e-invoice — against the 16 mandatory particulars the EU VAT Directive lists, plus the arithmetic. This is NOT an XML validator (use check_peppol_invoice or check_xrechnung for that). Input is "Label: value" lines; labels are matched loosely ("Invoice no", "Bill to", "Subtotal", "Amount excluding VAT" all resolve). Anything it cannot find is reported as missing rather than guessed. THE SCENARIO DECIDES WHICH PARTICULARS APPLY: from the two VAT number prefixes the tool works out domestic vs intra-EU B2B vs export, and only then requires the customer VAT number. When both prefixes are not present it returns scenario "unknown" and requires nothing extra — guessing would either invent a requirement or hide one. ARITHMETIC FINDINGS CARRY OFFICIAL EN 16931 RULE NUMBERS (BR-CO-15 for total = net + VAT, BR-CO-17 for VAT = taxable × rate), quoted verbatim from the published Peppol rule set — the same identifiers an access point will cite when it rejects the e-invoice version later. Report those identifiers as-is; they are checkable against official documentation. Also flags: zero VAT with no exemption basis stated, VAT charged to a VAT-registered customer in another member state, malformed VAT numbers (INV-015) and VAT numbers that fail their country check digit (INV-016 — a stronger signal). Limits stated rather than hidden: national add-ons beyond the directive are NOT covered, VAT numbers are not verified against VIES (that needs a network call), and this is not tax advice. Returns { fields, particulars[{id, label, status: present|missing|not-applicable, detail?}], findings[], summary{scenario, present, required, errors, warnings, supplierCountry?, customerCountry?, arithmetic{net,vat,gross,expectedVat,expectedGross}, byRule} }.

Given a VAT category code (S, Z, E, AE, K, G, O, L, M, B), return every EN 16931 / Peppol rule that applies to invoices using it — official identifiers and rule text quoted verbatim from the published rule set. Use this before building or judging an invoice with a non-standard VAT category: the reverse-charge family alone carries ten rules about what the VAT breakdown must contain, what the rate must be, and when an exemption reason is mandatory. Returns { code, family, rules[{id, text, severity}] }. An unknown code returns an empty rule list rather than a guess.

Search or resolve the code lists an electronic invoice is judged by: invoice type (UNCL1001), VAT category (UNCL5305), payment means (UNCL4461) and allowance reason (UNCL5189). THE POINT IS NOT THE LABEL. Telling someone "AE means reverse charge" is nearly useless; what matters is that choosing AE brings a whole family of official rules into force. For a VAT category code this tool returns those rules VERBATIM with their official identifiers (BR-AE-01 … BR-AE-10), so an agent can check the invoice against them or quote them to a user. Values that get chosen wrongly, worth knowing: 380 (commercial invoice) sent for what is actually a credit note; 30 (generic credit transfer) where the receiver expects 58 (SEPA credit transfer); and E / O / Z used as synonyms when exempt, outside-scope and zero-rated are three different rule families. L and M exist because the Canary Islands (IGIC) and Ceuta/Melilla (IPSI) sit outside the EU VAT area. When a code is not in a list, that is reported as such along with the nearest codes — a value outside the list is rejected by the receiving system rather than interpreted. Pass `code` with `list` to resolve one value, or `query` to search all four lists by code or meaning. Returns either { list, entry?, neighbours[], rules?[] } or { hits[{code, name, listId, listTitle}] }.