Aminus

Inspiration Invoice fraud is not a niche problem — it is the fastest-growing financial crime targeting businesses today. With generative AI, criminals can now produce fake supplier emails and manipulated PDFs at industrial scale. A single changed IBAN on a single invoice can silently redirect tens of thousands of euros to a fraudulent account.

At the same time, France is mandating electronic invoicing for all businesses starting September 2026, forcing hundreds of thousands of SMEs to process structured XML invoices — a standard most of them have never heard of.

We looked at the intersection of these two forces — a regulatory shift and an AI-powered fraud wave — and asked: what would an intelligent, automated control layer look like? That question became Aminus.

What We Built Aminus is an AI invoice screening plugin that sits on top of a company's existing ERP system. Every invoice received by email passes through a two-stage automated pipeline:

Stage 1 — Security Check

The new French e-invoicing regulation (and the broader European EN 16931 standard) requires invoices to embed structured XML data (Factur-X). Our system extracts that XML and simultaneously runs Claude Vision on the visible PDF — reading it exactly as a human would. We then compare the two extractions field by field:

$$\text{fraud signal} = \exists, f \in F : \text{XML}(f) \neq \text{Vision}(f)$$

Where $F$ is the set of critical fields: supplier_name, invoice_number, total_amount, IBAN, currency, invoice_date. Any meaningful discrepancy triggers an immediate Danger flag before any payment can be initiated.

Stage 2 — ERP Reconciliation

If the invoice passes the security check, a Claude AI agent queries the company's ERP context — vendor profiles, open purchase orders, and payment history — and applies structured reasoning:

Decision Condition already_paid Invoice reference exists in payment history → duplicate, block not_yet_paid Vendor + IBAN + amount match an open PO (within ±25% TVA tolerance) danger IBAN on invoice ≠ vendor's registered IBAN → BEC fraud signal needs_review No plausible PO match, no fraud signal → escalate to accountant The full reasoning chain is logged in an immutable audit trail — every decision is explainable and auditable.

How We Built It We built the entire stack from scratch during the hackathon:

Frontend — Next.js with a real-time invoice queue dashboard, live audit trail panel, and drag-and-drop PDF upload Backend — FastAPI serving the two-stage screening pipeline via a single /invoices/screen endpoint AI Layer — Anthropic Claude (claude-sonnet-4-6) for both vision extraction and agentic ERP reconciliation Database — Supabase (PostgreSQL) for invoice persistence and ERP context simulation Infrastructure — One-command startup script (start_mvp.sh) handling dependency installs, frontend build, and process management The security check cross-references two independent extraction paths — structured XML parsing via factur-x and visual extraction via Claude Vision — making it robust against both accidental data errors and deliberate document manipulation.

Challenges We Faced

1. Parsing multilingual, multi-format invoice amounts French invoices use fr-FR locale formatting — spaces as thousands separators and commas as decimal points (6 600,00 €). Our initial parser treated spaces as insignificant and stripped them, turning 6 600,00 into 660000 — a 100× error. We had to implement locale-aware parsing that detects the format before converting.

2. Making Claude's reconciliation decisions reliable Early versions of the ERP reconciliation prompt would return inconsistent JSON, mix prose with structured output, or self-correct mid-response. We solved this with strict prompt engineering, a JSON extraction fallback that scans for the last valid {"decision": ...} block in the response, and a model fallback chain that retries across available Claude versions.

3. Balancing fraud sensitivity without false positives The security comparison needed to flag real discrepancies — a changed IBAN, a manipulated amount — without triggering on formatting differences, null fields, or minor whitespace variations. We built a field normalizer and a meaningful-diff filter that ignores null-vs-null noise while remaining strict on financially critical fields.

4. Building a full product in 24 hours Scope control was the hardest challenge. We had to make fast architectural decisions — a single screening endpoint rather than a multi-service architecture, a simulated ERP context rather than a real integration — while keeping the product demo-ready and the core AI pipeline genuinely functional on real invoices.

What We Learned Factur-X is underused and underappreciated. The embedded XML standard is already present in many European invoices — but almost no tooling exploits it for security. The gap between what the standard enables and what companies actually use is the exact space Aminus lives in. Claude Vision is remarkably accurate at structured data extraction from financial documents — matching or exceeding what we expected from dedicated OCR pipelines, with the added advantage of contextual understanding. The regulatory tailwind is real. The 2026 French mandate is not optional — it creates a forcing function that makes the problem we're solving urgent, not hypothetical.

Built With

• anthropic
• anthropic-python-sdk
• api
• css
• factur-x
• fastapi
• intl-(locale-aware-number-formatting)-infrastructure-bash-(one-command-startup-script)
• languages-python
• next.js
• next.js-(react)-ai-/-apis-anthropic-claude-api-(claude-sonnet-4-6)-?-vision-extraction-+-agentic-erp-reconciliation-database-supabase-(postgresql)-standards-factur-x-/-en-16931-(european-structured-e-invoice-xml)-libraries-factur-x-(xml-extraction)
• postgresql
• python-dotenv
• react
• rest
• supabase
• typescript
• typescript-frameworks-fastapi
• uvicorn