Every invoice your AI approves is a wire transfer. Claude is genuinely good at reading incoming invoices, matching them against purchase orders and receipts, and flagging what doesn't line up. The question is what happens the moment "clear it" means moving money — approving a payment, updating a vendor's bank details, releasing a wire. That's where "Claude wrote a good AP bot" and "a runtime enforces your payment controls" stop being the same claim.
Support tickets are occasionally hostile. Sales negotiations are persuasive by design. An accounts-payable inbox is different again: it's the single most consistently attacked channel in corporate finance, because a convincing invoice email is one of the oldest, cheapest, and most effective ways to move money that isn't yours. An AI reconciliation agent doesn't need to be hacked — it just needs to believe the email. Neither approach is fooled by urgency or a plausible-looking sender. The real question is what stands between that email and the bank account actually changing.
The invoice-matching and vendor-update logic are functions in the same codebase. Whether a bank-detail change and a same-day payment both go through depends on the prompt and guardrail code catching this specific combination — a pattern fraud rings actively test against.
Claude can match the invoice to the PO and receipt. The cloudlet checks the vendor-bank-change request against this role's capability grant — updating remittance details isn't in an AP clerk's grant at all. It's refused and routed to a separate, out-of-band-verified workflow.
Ask any finance-AI vendor this and the marketing sounds identical — "controlled," "SOX-ready," "human in the loop." The architecture underneath does not. There are, in practice, exactly two answers.
A Magic Cloudlet exposes your ERP and payment systems to Claude as a set of generated, role-gated endpoints — handed to it as MCP tools rather than a service account with broad access. The agent's token carries a role, the same way a human AP clerk's login does. An AP-clerk role matches invoices and flags exceptions; a controller role approves within threshold; vendor bank-detail changes require a distinct, verified workflow no reconciliation role can shortcut — regardless of how urgent the email sounded.
Trust boundary, left: the prompt and your guardrail code. Right: the runtime. Attack surface shrinks from every action your code exposes to only the actions this role's grant allows.
The checklist a security-conscious controller should put in front of a CFO before letting an AI agent touch a live payment run.
| # | Requirement | Claude alone, free-form | Magic Cloudlet + Claude |
|---|---|---|---|
| 1 | ERP / accounting connection | ManualCustom integration per platform (NetSuite, SAP, QuickBooks…). | HandledGenerated endpoints wrapping your existing system — zero migration. |
| 2 | Invoice ingestion (email, EDI, portal) | ManualBuilt and maintained by your engineering team. | HandledGenerated alongside the rest of the endpoint surface. |
| 3 | 3-way match logic (PO / receipt / invoice) | ManualWritten into application code by hand. | HandledGenerated as a validated matching endpoint. |
| 4 | Vendor master data change controls | ManualA bug here is a fraudulent wire — the classic BEC vector. | HandledA separate capability grant, structurally outside AP-clerk reach. |
| 5 | Payment approval thresholds | ManualWritten into application code; a bug here is unauthorized spend. | HandledA capability grant with a dollar cap, enforced at every call. |
| 6 | Exception routing | ManualCustom logic for mismatches, duplicates, anomalies. | HandledGenerated as an endpoint the role can call, not bypass. |
| 7 | Role tiers (clerk / manager / controller / treasury) | ManualHand-rolled middleware, one implementation per build. | HandledRuntime-native roles — same object, token to admin screen. |
| 8 | Fraud / injection defense | ManualFilters and hardening — a defense fraud rings actively test. | HandledAn urgent-sounding request still can't exceed the capability grant. |
| 9 | Audit trail of matches & payment releases | ManualDesigned, instrumented, and wired to a log store. | HandledBuilt-in, filterable log — every match, every release, every change. |
| 10 | Security review before launch | ManualFull human review of every generated line. | PartialStructural checks handle validity; exception logic still reviewed. |
| 11 | SOX / internal controls scope | ManualOngoing, and specific to your controls framework. | PartialSelf-host / air-gap keeps infra in your boundary; scope mapping is still yours. |
| 12 | Hosting, deploy, rollback | ManualA DevOps project, built once a backend exists. | HandledIncluded with a managed cloudlet, or self-hosted / on-prem / air-gapped. |
| 13 | Ongoing patching & maintenance | ManualYour team, indefinitely, as each ERP API and fraud pattern evolves. | PartialMaintained by Nuity (managed), or self-maintained under the MIT license. |
A security reviewer's real question isn't "is the model careful." It's "what, mechanically, refuses the payment or vendor change this role shouldn't be able to make" — no matter how urgent or plausible the email looked.
| Layer | Claude alone, free-form | Magic Cloudlet + Claude |
|---|---|---|
| Action vocabulary | Open — any function your integration code exposes, reachable if the prompt gets there. | Closed — a finite, registered set of actions per role. |
| Pre-execution verification | Prompt hardening and application-level checks, written by hand. | A static proof against the live capability registry, before delivery. |
| Capability grants (payment cap, vendor-data scope) | Not native — hand-built into the payment / vendor-update functions. | Argument-bound grants, checked by the evaluator at every dispatch. |
| Identity & role (clerk vs controller vs treasury) | A middleware pattern each new build may implement differently. | A runtime object — one role, from the agent's token to the admin screen. |
| Audit trail | Whatever your team designs, instruments, and maintains. | Built-in, severity-tagged log of every match, release, and change. |
Everything on the right is enforced at the moment of dispatch, by the evaluator, on every call — not by a prompt the next well-crafted fraud email is free to argue with. That difference is architectural, not behavioral. It doesn't degrade as invoice volume, or fraud sophistication, goes up.
Self-hosted, the runtime is free and MIT-licensed. Managed, it's a flat $100/mo with one developer user included. The reference backend build runs roughly 80% fewer AI tokens than hand-building the same integration and control logic from scratch — about 25,000 tokens versus 140,000. Set that against the figures below, which are the FBI's, not ours.
Reported business email compromise losses in 2025, up from $2.77B the year before — the exact fraud pattern AP inboxes face daily.
Average reported loss per BEC complaint — often a single fraudulent invoice or vendor-bank change.
Of BEC funds move via wire transfer or ACH — fast, and frequently unrecoverable once sent.
Source: Federal Bureau of Investigation, Internet Crime Complaint Center (IC3), 2025 Internet Crime Report. Figures are national totals and averages across all reported BEC incidents, not specific to AI-driven AP automation, and not a Nuity AI estimate. Token and cost figures are Nuity AI's published estimates as of mid-2026, based on a reference build (two linked tables, eight CRUD endpoints, access locked to a single role). Full methodology: nuity.ai/savings-calculator. This page is not audit, controls, or legal advice; SOX and internal-controls requirements vary by company.
$100/month buys a hosted, role-gated AP/AR runtime with enforced payment limits, segregated vendor-data controls, and a full audit trail — a rounding error next to the $122,000 average loss on a single successful BEC attempt.
A case a budget approver can trust has to concede real points, not just make them.
Two pages — the checklist, the security model, the numbers, and the ask — built to forward. The ten-page version has the full walkthrough for anyone who wants the detail.
Nuity AI's engineers will scope it against your actual ERP, your actual approval thresholds, and this exact comparison — live, no sales deck. This use case is a proposed pattern, not yet a shipped case study; we'll show you the mechanism, not a slide.