Skip to main content
Glama
Invoket
by Invoket

Compute late-payment interest and recovery compensation (EU, Directive 2011/7)

invoice_late_payment

Calculate statutory late-payment interest on unpaid B2B invoices under EU Directive 2011/7/EU, split period-by-period with national rates and fixed recovery compensation.

Instructions

Before your agent sends a dunning letter or books a receivable: what is legally due on an unpaid B2B invoice. Post the claim (amount, currency, country, due date - or invoice date plus agreed terms - and payment date) and get late-payment interest computed PERIOD BY PERIOD under Directive 2011/7/EU: the reference rate changes every 1 January and 1 July, so a claim straddling several half-years is split into tranches, each at the rate of its own half-year - applying today's rate to the whole period is simply wrong. Statutory rate = ECB main refinancing rate (NBP reference rate for Poland) plus the national margin, with the national transposition actually applied: France 10 points, Germany 9 on the Basiszinssatz base, Belgium rounding the reference up to the half point, 8 points elsewhere. Covers FR, DE, ES, IT, NL, BE, PT and PL, with an explicit fallback to the Directive minimum for the other Member States - a national rule is never guessed. Adds the fixed recovery compensation of Art. 6 (EUR 40, tiered in Poland), each component cited to its article. Paying on time is a valid answer, not an error. Price: $0.01 per call First call each day free (trial). Docs: https://invoket.com/docs/api/invoice-late-payment

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountYesPrincipal of the unpaid claim, simple decimal string, strictly positive. currency is ISO 4217 and required (XXX and XTS refused). Interest is computed in the currency of the claim while the fixed compensation is in euros by the Directive: outside the euro, total_due is null and a note says so - NO conversion is performed
countryYesMember State whose transposition applies, ISO 3166-1 alpha-2 (EL accepted for GR), required. FR, DE, ES, IT, NL, BE, PT and PL carry their own national rule; any other Member State gets the Directive minimum, explicitly flagged rule_source eu_minimum_fallback. A third country is refused (unsupported_country): the Directive governs commercial transactions within the Union, and no rule is guessed beyond it
currencyYes
due_dateYesContractual due date. Alternatively supply invoice_date plus payment_terms_days; with neither, the national statutory default applies and the response says so. A term beyond the 60-day legal cap is NOT refused: it is computed as supplied, with a note recalling the cap may make it unenforceable. Dates must be real calendar dates, and a date outside the snapshot coverage (before 2011, or beyond the last published half-year) is a 400 date_out_of_range - the rate of an unopened half-year is never extrapolated
paid_dateYesDate of payment or of the assessment, defaulting to today. Paying on time is a valid, paid answer: days_late 0, total_due 0, flat_fee.source not_due, with the rationale citing art. 3(1). An optional contractual_rate (annual, in points) applies ONLY if it exceeds the statutory rate, which stays a public-policy floor (art. 7); otherwise the statutory rate applies and a note says so
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so richly. It reveals period-by-period tranche computation ('the reference rate changes every 1 January and 1 July'), national margin details (FR 10, DE 9), currency handling (NO conversion, total_due null outside euro), country coverage (FR/DE/ES/IT/NL/BE/PT/PL plus explicit EU-minimum fallback), refusal behavior (third country refused), date bounds (date_out_of_range), and pricing ($0.01/call, free daily trial). It even discloses that a term beyond the 60-day cap is computed as supplied rather than refused—substantial transparency.

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

Conciseness4/5

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

The description is dense and front-loaded with the core value proposition, then layers in edge cases and disclaimers. Every sentence adds operational information—the only minor deduction is that the pricing and docs block, while useful, couples business pricing with tool semantics, and a couple of behavioral details (NBP for Poland, half-point Belgian rounding) could arguably belong in schema or docs rather than the headline description. Still, it's tightly written with zero filler.

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

Completeness5/5

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

Despite having no output schema and a moderately complex parameter space (5 required params), the description fully specifies inputs, outputs (total_due, flat_fee, day_late, rule_source), behavior under every edge case (on-time, out-of-range dates, term beyond cap, third-country, non-euro), and fallback logic. The legal citation (art. 3(1), art. 6, art. 7) and country rules are all disclosed. Nothing essential is left underspecified for a computation of this complexity.

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 coverage is 80%, with 4 of 5 parameters carrying rich descriptions. The description adds meaning beyond the schema by explaining the due_date alternatives (invoice_date + payment_terms_days), the statutory default behavior, the date_out_of_range bounds, the paid_date 'on-time is valid' semantics, and the optional contractual_rate override logic. currency's XTS/XXX refusal and total_due-null behavior are explained. Only plain 'currency' and the un-parameterized extras are not enumerated as separate fields, but the description covers them inline.

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 uses a specific verb+resource ('Compute late-payment interest and recovery compensation') and scopes it precisely to EU Directive 2011/7 for unpaid B2B invoices. It distinguishes itself clearly from sibling tools ('Before your agent sends a dunning letter or books a receivable: what is legally due on an unpaid B2B invoice') and is distinct from the invoice_* family which handles validation/generation/reading per the sibling list.

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

Usage Guidelines5/5

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

The description explicitly states when to use the tool ('Before your agent sends a dunning letter or books a receivable'), what inputs to provide, and clarifies edge cases like 'Paying on time is a valid answer, not an error' and 'a national rule is never guessed.' It distinguishes from the broader invoice_* and legal_* tools by positioning it specifically as the late-payment computation endpoint.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Invoket/mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server