e-arveldaja MCP Server

Create Purchase Invoice from PDF

create_purchase_invoice_from_pdf

Create a draft purchase invoice from PDF data and attach the source file, preserving exact VAT/gross totals to avoid recalculation errors.

Instructions

Create a draft purchase invoice from extracted document data and attach the source file. Direct-call contract: pass exact invoice vat_price/gross_price when known, never recalculate; non-EUR requires currency_rate (EUR per 1 foreign unit); base_* may lock actual EUR settlement.

Input Schema

TableJSON Schema

Name	Required	Description
`items`	Yes	Items [{custom_title, cl_purchase_articles_id, purchase_accounts_id, purchase_accounts_dimensions_id?, total_net_price, vat_rate_dropdown?, amount?, vat_accounts_id?, vat_accounts_dimensions_id?, cl_vat_articles_id?, reversed_vat_id?}]. purchase_accounts_dimensions_id is REQUIRED when the expense account has dimensions; same for vat_accounts_dimensions_id on dimensioned VAT accounts.
`notes`	No	Optional notes (assumptions made, manual adjustments). Do NOT use the source document filename — the document is already uploaded and attached.
`currency`	No	Currency code (default EUR). Use the original invoice currency (e.g. USD) and supply currency_rate.
`file_name`	No	Name for the uploaded document (e.g. the original filename for base64 input); defaults to the source file's name. The file's extension is kept.
`file_path`	Yes	Absolute path to the source invoice document (PDF/JPG/PNG); uploaded during creation.
`term_days`	Yes	Payment term days
`vat_price`	No	EXACT total VAT from the original invoice; never recalculate. Omit only if truly absent from the document.
`ref_number`	No	Reference number
`gross_price`	No	EXACT total gross from the original invoice; never recalculate. Omit only if truly absent from the document.
`invoice_date`	Yes	Invoice date (YYYY-MM-DD)
`journal_date`	Yes	Turnover/booking date (YYYY-MM-DD)
`currency_rate`	No	Exchange rate as EUR per 1 foreign currency unit. Required when currency != EUR.
`source_sha256`	Yes	SHA-256 of the document returned by extract_pdf_invoice; binds this booking to the exact reviewed bytes.
`base_net_price`	No	EUR equivalent of net_price; auto-derived from currency_rate when omitted.
`base_vat_price`	No	EUR equivalent of vat_price; auto-derived from currency_rate when omitted.
`invoice_number`	Yes	Invoice number
`bank_account_no`	No	Supplier bank account
`base_gross_price`	No	Actual settled EUR gross total; auto-derived from currency_rate when omitted.
`block_on_duplicate`	No	Refuse creation when this receipt's cash outflow looks like an already-booked duplicate (default false: warn only).
`supplier_client_id`	Yes	Supplier client ID (from resolve_supplier)
`liability_accounts_id`	No	Liability account (default 2310)
`allow_duplicate_invoice_number`	No	Explicit acknowledgement that the supplier reuses this invoice number (e.g. across years): an existing live invoice with the same supplier and number becomes a warning instead of a refusal (default false: refuse).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.27.0Sep 26, 2026

addedInput schema / properties / allow_duplicate_invoice_number

Added value: +{
+  "description": "Explicit acknowledgement that the supplier reuses this invoice number (e.g. across years): an existing live invoice with the same supplier and number becomes a warning instead of a refusal (default false: refuse).",
+  "type": "boolean"
+}

addedInput schema / properties / file_name

Added value: +{
+  "description": "Name for the uploaded document (e.g. the original filename for base64 input); defaults to the source file's name. The file's extension is kept.",
+  "type": "string"
+}

Changed3 schema fields changedv0.25.2Jul 26, 2026

addedInput schema / properties / block_on_duplicate

Added value: +{
+  "description": "Refuse creation when this receipt's cash outflow looks like an already-booked duplicate (default false: warn only).",
+  "type": "boolean"
+}

addedInput schema / properties / source_sha256

Added value: +{
+  "description": "SHA-256 of the document returned by extract_pdf_invoice; binds this booking to the exact reviewed bytes.",
+  "pattern": "^[0-9a-f]{64}$",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "supplier_client_id",
-  "invoice_number",
-  "invoice_date",
-  "journal_date",
-  "term_days",
-  "items",
-  "file_path"
-]New value: +[
+  "supplier_client_id",
+  "invoice_number",
+  "invoice_date",
+  "journal_date",
+  "term_days",
+  "items",
+  "file_path",
+  "source_sha256"
+]

First observedv0.18.1Jul 9, 2026

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already show a non-read-only, non-destructive mutation, and the description adds real behavioral detail: it creates a draft, attaches the source, forbids recalculation, and notes that base_* may lock EUR settlement. It does not mention duplicate-warning/refusal behavior, but that is not a contradiction and schema covers it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences pack the core purpose plus the most safety-critical call rules with no filler. The primary action is front-loaded, and the dense second sentence is all high-value guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 22-parameter creation tool, the description plus full schema coverage is nearly complete: it identifies the extraction pipeline, exact-total rules, currency handling, and EUR-base locking. It does not describe the return value or post-creation confirmation step, which would matter since there is no output schema, but this is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; the description's 'contract' adds interconnected call semantics beyond the individual fields, especially that base_* values can lock the settled EUR amount rather than just being derived. Most parameter meaning still comes from the schema, which is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Create a draft purchase invoice') plus the distinctive source ('from extracted document data') and side effect ('attach the source file'). It reads as distinct from sibling create_purchase_invoice by tying itself to an extraction pipeline.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'From extracted document data' and 'Direct-call contract' establish the intended post-extraction, careful-call context, and the rule to pass exact totals. However, it never explicitly contrasts this with create_purchase_invoice or states when not to use this variant, so the guidance relies on inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Create Purchase Invoice from PDF

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools