Frequently asked questions

ADI detects four patterns from the invoice document alone — payment hijacking and bank account substitution, vendor impersonation and typosquatting, coercion and urgency language designed to bypass approvals, and document forgery signals such as conflicting field values across sections.

Patterns that require historical data — duplicate invoices, overbilling against contracted rates, unusual billing frequency, and vendor legitimacy verification — require access to your ERP or AP ledger. These are on ADI's integration roadmap and are discussed during the POC scoping call.

Invoice data is processed in-memory only and discarded immediately after the response is returned. Nothing is written to disk, database, or cloud storage. For production deployments, ADI supports local LLM deployment where invoice data never leaves your infrastructure.

In the current demo environment, AI reasoning uses OpenAI's API. For enterprise deployments, ADI supports local LLM deployment using Mistral — meaning invoice data never leaves your environment and no third-party AI is involved.

ADI is an advisory layer that sits alongside your existing systems. It flags fraud signals and validation issues — your team and your existing workflows make the final payment decisions. Nothing changes in how your ERP or approval process works.

No. ADI is advisory by design — it never blocks, approves, or rejects a payment automatically. It flags fraud signals, validates rules, and explains its reasoning. Every final decision stays with your team and your existing approval workflows. ADI gives your reviewers better information, not less control.

ADI is built natively on Java 21 and Spring Boot 3.4. It integrates via clean REST APIs and requires no changes to your existing architecture, schema, or approval workflows.

ADI exposes clean REST APIs, so any system that can make an HTTP request can integrate with it — regardless of the underlying technology. That said, ADI is purpose-built and optimised for Java and Spring Boot environments. If your core finance or AP system runs on a different stack, integration is still possible but the implementation path is discussed during the scoping call.

A typical pilot runs 3–4 weeks. You provide a sample of invoices, ADI runs fraud detection and validation, and we deliver a findings report with every flag explained and an integration path for your Spring Boot system.