Skip to main content
Glama

Audit Creditor File

audit_creditor_file

Validate an entire creditor/supplier payment file before sending: checks IBAN structure, duplicate accounts, BIC consistency, country mismatches, and SEPA reachability.

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 — and sheets over 20,000 rows, which the route itself 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_chf / 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 CHF up to 5,000 rows, 349 CHF 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
NameRequiredDescriptionDefault
langNoLanguage for the summary labels and, later, the annotated report. Defaults to "en".
checkoutNoWhen 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.
filenameYesOriginal filename with its extension, e.g. "creditors.csv" or "suppliers.xlsx". The extension decides how the file is parsed.
file_base64YesThe CSV or XLSX file content, base64-encoded — the raw payload only, no "data:" URL prefix.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobYesJob id — pass to audit_status to poll payment and get the download link.
langNo
paidYesAlways false from this tool — nothing has been paid yet.
rowsYes
tierNo
_noteNoPlain-language reminder that this is a free preview and how to get the paid report.
previewYesFirst flagged rows then first OK rows, up to 20. IBANs are masked.
summaryYesCounts by status and finding code, countries seen, columns detected. Mirrors AuditSummary in the API.
checkoutNoRoute to call for payment, e.g. "POST /v1/audit/checkout/{job}". Null once paid.
currencyNo
downloadNoSet only once paid and with the matching session — always null from this tool.
price_chfNoPrice of the full report in CHF, decided by row count alone.
retentionNoHow long the job is kept before it purges.
checkout_urlNoPresent only when `checkout: true` was passed and the session was created: a Stripe Checkout URL for a human to open.
checkout_session_idNoPresent alongside checkout_url — pass it to audit_status as `session_id` right after a human pays.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.0

TDQS

A4.6/5.0
Behavior5/5

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

The description thoroughly discloses behavioral traits: returns preview only, never pays automatically, always requires human checkout for payment, and outlines the exact return structure and limitations. No contradiction with the title-only annotation.

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 clear sections (purpose, when, how, limits, returns, cost). Each sentence adds value, though some redundancy exists (e.g., base64 encoding mentioned twice), preventing a perfect score.

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 an output schema, the description provides an excellent overview of the return fields (job, preview, summary, etc.), cost structure, payment process, and limitations, giving a complete picture for effective usage.

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

Parameters3/5

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

The input schema already covers all parameters with descriptions (base64 encoding, filename extension, lang, checkout). The description reiterates these points but adds no new semantic meaning beyond what the schema provides, warranting the baseline score for high schema coverage.

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 clearly states the tool audits an entire creditor/supplier payment file with specific checks (IBAN, BIC, SEPA, etc.) and explicitly distinguishes it from single-IBAN checks, making its purpose unambiguous.

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?

It explicitly provides 'USE WHEN' conditions (batch file checking before payments) and explains the payment flow, including when to use checkout and how to poll status, giving clear guidance on appropriate usage.

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