IBANforge

Audit Creditor File

audit_creditor_file

Detect errors in vendor payment batches before sending: validates IBANs, bank codes, BICs, SEPA reachability, duplicates, and address mismatches across the whole CSV/XLSX file.

Instructions

Audit an entire creditor/supplier payment file (CSV or XLSX) row by row: IBAN structure and checksum, bank code against the national register, bank name and BIC, SEPA reachability and issuer type — plus checks a single IBAN call cannot make because they need the whole file: duplicate IBANs, the BIC the file carries against the BIC the register derives, address country against IBAN country, and Swiss structured-address conformity ahead of the 14 November 2026 deadline. USE WHEN: the user has a spreadsheet or export of creditor/supplier bank accounts (accounts-payable file, vendor master, payment batch) and wants it checked before sending payments, or asks to "audit my creditor file" / "check this supplier list" / "validate this payment batch". HOW: base64-encode the file bytes and pass them as file_base64, with the original filename (its extension decides CSV vs XLSX parsing). LIMITS: rejects files decoding to more than 5 MB — checked locally, before any network call, because a larger base64 payload breaks the stdio channel; the HTTP route itself accepts up to 10 MB — and sheets over 20,000 rows, which the route rejects (400 too_many_rows). RETURNS a FREE PREVIEW ONLY, never the full report: job (the id to reuse with audit_status), rows, paid (always false from this call), price / currency naming what the full report costs, summary (counts by status and finding code, countries seen, columns detected), and preview (the first flagged rows then the first OK ones, up to 20, IBANs masked like "CH10 **** 2346"). The annotated .xlsx report is a PAID deliverable — $149 up to 5,000 rows, $349 up to 20,000 — settled through a one-off Stripe Checkout Session. This tool NEVER pays automatically: pass checkout: true to also receive a Checkout URL for a HUMAN to open, then poll audit_status with the same job id to learn when it is paid and get the download link. COST: free. Only the full report is paid, and only once a human completes the Stripe checkout.

Input Schema

TableJSON Schema

Name	Required	Description
`lang`	No	Language for the summary labels and, later, the annotated report. Defaults to "en".
`checkout`	No	When true, immediately create a Stripe Checkout Session after the upload and return its URL for a human to open and pay. Defaults to false. Never pays anything by itself.
`filename`	Yes	Original filename with its extension, e.g. "creditors.csv" or "suppliers.xlsx". The extension decides how the file is parsed.
`file_base64`	Yes	The CSV or XLSX file content, base64-encoded — the raw payload only, no "data:" URL prefix.

Output Schema

TableJSON Schema

Name	Required	Description
`job`	Yes	Job id — pass to audit_status to poll payment and get the download link.
`lang`	No
`paid`	Yes	Always false from this tool — nothing has been paid yet.
`rows`	Yes
`tier`	No
`_note`	No	Plain-language reminder that this is a free preview and how to get the paid report.
`price`	No	Price of the full report, in the currency given by `currency` (USD), decided by row count alone.
`preview`	Yes	First flagged rows then first OK rows, up to 20. IBANs are masked.
`summary`	Yes	Counts by status and finding code, countries seen, columns detected. Mirrors AuditSummary in the API.
`checkout`	No	Route to call for payment, e.g. "POST /v1/audit/checkout/{job}". Null once paid.
`currency`	No
`download`	No	Set only once paid and with the matching session — always null from this tool.
`retention`	No	How long the job is kept before it purges.
`checkout_url`	No	Present only when `checkout: true` was passed and the session was created: a Stripe Checkout URL for a human to open.
`checkout_session_id`	No	Present alongside checkout_url — pass it to audit_status as `session_id` right after a human pays.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.8.0Sep 26, 2026

addedOutput schema / properties / price

Added value: +{
+  "description": "Price of the full report, in the currency given by `currency` (USD), decided by row count alone.",
+  "type": "number"
+}

removedOutput schema / properties / price_chf

Removed value: -{
-  "description": "Price of the full report in CHF, decided by row count alone.",
-  "type": "number"
-}

Addedv1.5.0Sep 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With only a title annotation, the description carries the full burden and does so thoroughly. It discloses return behavior (free preview only, never full report), size limits (5MB decode, 20,000 rows), cost structure, checkout flow, and that it never pays automatically. This is far beyond what annotations provide.

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 long but well-structured, with the core purpose front-loaded and sections for USE WHEN, HOW, LIMITS, RETURNS, and COST. Every section earns its place; though it could be trimmed, the density is justified by the tool's complexity.

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?

The description covers everything an agent needs: what it does, when to use it, how to call it (including encoding and filename), what it returns (even naming fields), limits, pricing, and the checkout/polling flow. Given the output schema exists, it also explains return values beyond the schema, making it fully complete.

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 100%, so baseline is 3, but the description adds practical meaning: it instructs to base64-encode the raw bytes without a data: prefix, explains that the filename extension decides parsing, and clarifies the lang default. This enriches the schema without redundancy.

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 states a specific verb and resource: 'Audit an entire creditor/supplier payment file (CSV or XLSX) row by row' and lists the exact checks performed. It also distinguishes itself from single-IBAN tools by noting checks that 'a single IBAN call cannot make', making its scope unmistakable.

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 'USE WHEN' section explicitly tells when to call this tool: when the user has a spreadsheet/export of creditor accounts and wants it checked before payments, or when they use phrases like 'audit my creditor file'. It also implicitly excludes single-IBAN use by contrasting with those tools, giving clear selection guidance.

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

Deploy Server