The tool-description rules found nothing in these descriptions. They look for instructions aimed at a model and for hidden characters; they cannot see what a tool does when it runs.
view_invoice_demoDemonstrate the engine on bundled synthetic samples only; never checks a user's invoice.
Use for product evaluation without a key. To check a supplied document, choose validate_invoice.
Choose sample=valid to inspect a passing CII invoice or sample=invalid to see the missing-buyer-name
finding. Both use the production XSD and EN 16931 engine; results may be cached for 24 hours for
the same engine version and input. Inspect validated_at and cached; a cache hit is not a fresh run.
Call with {} to validate the passing sample, or sample=downloads for PDF/CII/UBL files and the
generate_invoiceCreate an EN 16931 e-invoice from structured data: Factur-X PDF/A-3, CII XML, or UBL 2.1 XML.
Use when you have the parties, lines and dates and need the document. To revise one, correct the input
and regenerate; save and deliver the returned file through your own system. Do not use when you already have a
visual PDF and CII XML: call embed_xml. To check a document you did not create here, call validate_invoice;
to read one, call extract_invoice.
Start invoice from get_invoice_example, replacing sample parties and dates. Leave totals and line
net_amount omitted to com
embed_xmlCombine a visual PDF you already have with CII XML into one Factur-X PDF/A-3.
Use for an existing visual invoice; use generate_invoice to render invoice data or produce UBL.
Match the PDF's parties, lines and totals to xml yourself: check examines only XML and cannot detect
disagreement with the visible PDF. The embedded profile comes from xml; neither check nor language
changes it. language does not translate the PDF.
Invalid input or failed rules return a tool error with no file; rule errors include ids. For a
findings report use validate_invoice. Success returns a
validate_invoiceCheck a Factur-X PDF, CII XML or UBL XML against EN 16931, and report the fields to fix.
Use when the caller supplies a document, including after corrections; use extract_invoice for business data.
With no document and only a request to try the product, choose view_invoice_demo instead.
Supply one source: nonblank xml overrides document_base64 without inspecting it. To check a PDF's
attachment, omit xml. check adds rules to the detected profile; it cannot change that profile.
Use base for non-French invoices to avoid French-field findings.
Returns validity and finding
extract_invoiceExtract invoice parties, dates, lines, totals and VAT as JSON for bookkeeping or matching.
Use validate_invoice for compliance; this performs no OCR or recalculation. Supply one source:
nonblank xml overrides document_base64 without inspecting it, so omit xml to extract a PDF's
attachment. include_xml returns that selected source for archiving or validation, not XML
reconstructed from fields. Extracted fields need mapping before use as generate_invoice input.
Returns fields and format/profile metadata, plus PDF metadata for PDF input. Missing business values
remain nu
check_partyCheck exactly one seller or buyer's registry identifiers and readiness through EU Verify.
Use to correct one party's identifiers; use check_invoice_parties to check seller and buyer together,
or validate_invoice for document rules.
Supply siren, siret or vat; siret wins over siren. A SIREN/SIRET, country_code=FR or FR VAT triggers
French checks requiring a SIREN/SIRET. Omitted vat can be derived from a successful French lookup;
foreign parties normally need explicit VAT. Send address fields with a coherent country_code;
requester_vat cannot substitute for the checked p
check_invoice_partiesCheck a supplied seller AND buyer together, returning combined readiness and separate evidence.
Use before generate_invoice; use check_party for one party and validate_invoice for document rules.
Each party needs siren, siret or vat; siret wins over siren. French identifiers or country_code=FR
require SIREN/SIRET; a French lookup can derive omitted vat. Address fields activate address checks.
requester_vat applies to both lookups but cannot replace either party's vat. Roles follow seller/buyer
argument names; no invoice lines or full invoice body is needed.
Makes at m
explain_findingTurn a validation rule id into the invoice field to change and an example value.
Use after validate_invoice or a generate_invoice rule error, not to validate an invoice itself.
rule is trimmed and uppercased to select a guide entry. message/json_pointer must come from that
same finding: nonempty values override its generic context, but never change the selected fix or
example. Omit them to use guide defaults for known rules.
Returns rule, known, message, json_pointer, fix and example; known rules also include problem.
Selected BR-FR rules and BR-CO-17/BR-CO-26 have gu
get_invoice_exampleReturn a complete invoice or credit-note example to edit and pass to generate_invoice.
Use this first, instead of inventing fields. No API key is required, and the call does not count
as a document. The seller and buyer are sample data: replace them, the number, the dates and the
lines before you generate. For credit_note, also replace preceding_invoices with the original invoice reference.
To credit a real invoice already in hand, use draft_credit_note instead of this synthetic example.
Amounts are positive decimal strings. Nothing is stored, and no file
is created. R
draft_credit_noteDraft a type-381 credit note from an existing invoice, for all lines or selected quantities.
Use to reverse an existing invoice's charges; use get_invoice_example for a synthetic credit-note example.
invoice must be the original generate_invoice input object, not extract_invoice output.
number and issue_date belong to the new credit note; the original number/date are copied into
preceding_invoices. Give number a distinct value and use YYYY-MM-DD dates. due_date replaces the
original deadline; omitting it removes that deadline rather than inheriting it.
Omit credit_lin
