The 5-Trait Test for AI-Native ERP

An ERP that needs human approval on every AI suggestion is a smarter search box, not an AI agent. The architectural test is whether the AI can autonomously submit a state-mutating action with an audit trail, or whether every write still ends at a human clicking Submit on a form.

A schema designed in the 1990s assumes a human is driving every write. A schema designed for AI agents has the action layer as the API, immutable audit logs as a primary table type, and the foreign-key topology built so an agent can traverse it without help.

If the AI translates intent into form-fills, it is a fancy text-to-form translator. If there is a programmatic action surface (an action per business operation, callable from chat, CLI, or web) the AI invokes the action directly. The latter is the architectural commitment.

An AI agent that posts an unbalanced journal entry can corrupt the books in seconds. The architectural defense is to enforce GL invariants (debits equal credits, period is open, accounts exist, currency matches) before the write, in the same transaction, with a clean rollback on failure.

If the AI is the architecture, every customer gets it. If the AI is an upsell, the vendor is positioning it as a premium feature on top of a non-AI base product. The pricing structure reveals which one is true.

Treating "AI suggests, human approves" as passing Trait 1

Trait 1 tests autonomous write capability, not suggestion quality. A workflow where the AI prepares a journal entry and a human clicks Submit is precisely what Trait 1 is designed to disqualify. The suggestion can be sophisticated, context-aware, and correct nine times out of ten; it still scores 5, not 10. The architectural question is narrow: can the AI invoke a state-mutating GL action without a human in the critical path? If the answer is no, the score is 5 at most, regardless of how intelligent the suggestion appears to the user.

Conflating a REST API with a native action layer (Trait 3)

Many ERPs expose a REST or GraphQL API for data sync and integration. A generic CRUD endpoint is not a native action layer. Trait 3 looks for a named action surface the AI calls by business operation: approve-invoice, recognize-revenue, post-accrual. The test is whether the AI calls an operation by name in a single-transaction, JSON-in JSON-out call, or whether it constructs raw HTTP requests against a CRUD endpoint to achieve the same result. The former is native. The latter is a workaround. Vendors with external integration APIs often claim Trait 3 on that basis; the workflow test in step 3 of the application guide will reveal which is which.

Using a bolted-on AI schema to claim Trait 2 compliance

Vendors who add AI-adjacent tables (conversations, intents, suggestions) to a pre-2020 schema sometimes score themselves high on Trait 2. The test is not whether AI-related tables exist; it is whether the core accounting tables were designed with AI as a primary user. The tell is in the original GL schema: money stored as a float rather than a fixed-precision type, mutable GL entries with an updated_at column, foreign keys unenforced at the database level, and no immutable audit table for AI invocations. A conversations table added in 2024 sits on top of an architecture that was not designed for agents, and Trait 2 reflects the underlying design, not the layer added later.

Scoring Trait 5 on plan names instead of pricing page evidence

"AI Professional" and "AI Business" are marketing labels, not pricing signals. Trait 5 has a single test: can a customer on the entry-level plan invoke an AI action that writes to the GL? The pricing page is the source of truth. If the AI write capability is absent from the lowest paid tier, Trait 5 scores 0 or 5 regardless of what the plans are named. Check the feature comparison table, not the plan name. The feature comparison table is where vendors hide the gate.

Missing the transaction requirement in Trait 4

Pre-write invariant enforcement is only meaningful if the validation and the write execute in the same database transaction. Some vendors enforce GL balance rules in application code before issuing a write, but the validation and the commit are separate calls. A concurrent write can land an unbalanced entry in the window between them. The architectural test is whether a validation failure triggers a rollback before any row is inserted. Batch reconciliation that catches imbalances after the write scores Trait 4 at 5; it catches errors but does not prevent them. The distinction matters for autonomous AI writes, where a correction loop is more expensive than a pre-write gate.