The 5-Trait Test for AI-Native ERP
Methodology for distinguishing AI-native architecture from AI-decorated overlays
Why this test exists
Every ERP vendor in 2026 claims "AI-powered." SAP markets Joule. Oracle markets AI Agents. Microsoft markets Copilot inside Dynamics 365. Sage, NetSuite, QuickBooks, Xero, Zoho, ERPNext, Odoo, every vendor in the category has an AI page. Most of those claims are AI-decorated overlays on forms-and-workflows systems designed before AI existed. A few are genuinely AI-native by architecture.
Buyers evaluating the category in 2026 cannot tell the two apart from marketing copy. The marketing copy is identical: every vendor says "AI-powered ERP." The architectural reality is not identical. This methodology is the test that tells them apart, expressed as five architectural traits a buyer can verify with public evidence.
This methodology is the foundation of the 2026 AI ERP Transparency Index, which extends the five traits into 12 measurable criteria scored across 50 vendors.
The five traits
Each trait is binary at the architectural level: the system either has it or does not. Vendors land in between because they have partial implementations or in-progress changes. The scoring rubric below covers the 10 (full), 5 (partial), and 0 (absent) scoring anchors for each trait.
AI writes to the GL directly
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.
Schema designed for AI agents
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.
Native action layer
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.
Pre-write invariant enforcement
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.
Single AI tier (no gating)
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.
Scoring rubric per trait
Each trait scored 0, 5, or 10. Intermediate scores allowed at the analyst's discretion when evidence supports a half-step (e.g., 3 if mostly absent with a single partial implementation, 7 if mostly present with one major gap). Every score must cite a public source.
Trait 1: AI writes to the GL directly
The AI invokes a state-mutating action through a programmatic surface. The action runs in a single transaction with full validation, posts to the GL, and writes an immutable audit row recording the AI's invocation, inputs, outputs, and exact GL entries. The customer can replay the action later.
The AI prepares a draft journal entry or a pre-filled form. A human reviews and clicks Submit. The audit log records the human submit, not the AI's role in preparing it. Practical for early adopters who do not yet trust autonomous AI; not autonomous architecture.
The AI summarizes or answers questions about data. It does not write anything back to the books. Read-only assistant; no write path at all.
Trait 2: Schema designed for AI agents
Schema designed with AI agents as a primary user. Action layer is the API. Money stored as Decimal in TEXT (not float). IDs are UUIDs. GL is immutable by schema (no updated_at). Audit log is a first-class table that the AI writes to on every invocation. Foreign keys enforced. The AI can introspect tables to answer questions.
Pre-AI schema with AI-related tables added in a recent release. The original tables (customers, invoices, GL entries) still assume human-driven writes. The AI-related tables (conversations, intents, suggestions) are bolted alongside. Backward-compatible but not native.
Pre-AI schema only. No tables related to AI invocations, AI audit, or agentic workflows. The vendor's AI lives entirely outside the database (a chatbot in the UI), not as a participant in the data model.
Trait 3: Native action layer
Every business operation is an action: kebab-case named, single-transaction, JSON in JSON out, fully documented in a module manifest. The AI calls the action by name. The same action runs from chat, CLI, web, or a programmatic API. There is no form-fill translation path.
Some operations have actions; many still go through forms. The AI partially invokes actions for read operations and form-fills for write operations. Mixed architecture.
No action layer. Every operation is a form. The AI's only write path is to pre-fill forms for a human to submit. Adding AI does not change the architecture; it just adds a smarter input method.
Trait 4: Pre-write invariant enforcement
Every GL posting runs through a multi-step validation pipeline before any row is inserted. Debits equal credits, period open, accounts exist, currency match, etc. Failure aborts the entire transaction. The AI cannot violate the GL even when it is wrong about something else. Invariants are documented and testable.
Some invariants enforced at write time. Some enforced by a post-write batch reconciliation job. Imbalanced entries can land temporarily and get caught later. Practical for legacy systems; not safe for autonomous AI.
No invariant enforcement at the data layer. Every safety check lives in the UI or in a nightly batch. An AI agent can post any row that fits the schema. Books can corrupt; cleanup is manual.
Trait 5: Single AI tier (no gating)
AI is available to every customer at every tier, free or paid, no upcharge. The vendor's pricing page does not separate AI features as a separate line item. The AI is the product, not an add-on.
AI available in mid-tier and above, gated out of the entry-level plan. Vendor positions AI as a paid premium feature.
AI only available in the enterprise tier, custom-quoted, gated behind a sales call. AI is a $50K+ annual add-on positioned as the premium offering on top of a forms-based base ERP.
How to apply the test to any ERP
Six-step process. Roughly 60 to 90 minutes per vendor for the first pass; faster once you have the rhythm.
- 1. Read the vendor's AI page. Capture the claims verbatim. The vendor's marketing language is the input, not the conclusion.
- 2. Find their developer documentation. Look for an action / API / SDK page. The presence and shape of the programmatic surface is the strongest signal for trait 3 (native action layer).
- 3. Watch a product demo or walkthrough. Pay attention to whether the AI invokes an action or pre-fills a form. The architectural answer is in the workflow, not the marketing.
- 4. Check the pricing page. Single AI tier vs gated AI tier vs enterprise-only AI = trait 5.
- 5. Score each trait 0, 5, or 10. Cite a public source per score. Sum and normalize: total / 50 * 100 = trait score (0 to 100).
- 6. Publish the score and the sources. If you are scoring publicly, accept the open challenge process: vendors may submit corrections backed by counter-sources.
How the 5-trait test extends to the 12-criteria Index
The 5 traits cover architecture. The 12 criteria in the Transparency Index cover architecture plus four additional dimensions that matter to a buyer beyond pure architecture: pricing transparency, customer data sovereignty, foundation-model disclosure, and architectural recency. The mapping:
| 5-trait test | Index criteria covered |
|---|---|
| Trait 1 (AI writes to GL) | Criterion 1 |
| Trait 2 (Schema for AI) | Criterion 2 |
| Trait 3 (Native action layer) | Criterion 3, plus reproducibility (criterion 7) |
| Trait 4 (Pre-write invariants) | Criterion 4 |
| Trait 5 (Single AI tier) | Criterion 5, plus pricing transparency (criterion 10) |
| Added in 12-criteria Index | Criteria 6 (open AI docs), 8 (foundation-model disclosure), 9 (data sovereignty), 11 (open source), 12 (architectural recency) |
The Index uses the 12-criteria rubric because buyers ask about all 12 dimensions. The 5-trait test is the cleaner version when an analyst wants the architectural answer only.
Open challenge process
Any vendor scored under this methodology may request a re-scoring with new evidence. The process is public and documented so the methodology stays credible.
- 1. File a public issue. On the GitHub repo for the artifact being challenged (for the Index, this will be
avansaber/ai-erp-transparency-indexwhen the Index publishes in Q3 2026). - 2. Cite the trait or criterion number. Specify which score you are disputing and what you propose as the corrected score.
- 3. Provide a public counter-source. Vendor documentation, press release, RFP response, product walkthrough video, or live demo. Private NDA evidence is not acceptable because the methodology requires reproducibility.
- 4. We respond within 14 days. If the counter-source is strong, we update the score, publish a correction in the changelog, and note the revision in the next annual edition.
- 5. All revisions are public. The changelog records every score change, the reason, and the source that triggered the change. The dataset history is preserved in git.
ERPClaw is a vendor in this category. AvanSaber Inc. self-scores using this methodology and accepts public challenges on its own scores the same way as on competitor scores. Self-scoring transparency is the trust signal that makes the methodology credible.
See the 2026 Index
The methodology is the foundation. The Index is the applied scoring against 50 ERPs across 12 criteria. Full ranking publishes Q3 2026; methodology and tier composition live now.