Two architectures, not two feature lists
AI-native has become a common label across enterprise software, and as the label has spread its meaning has become less precise. AI-native and AI-enabled are not synonyms. AI-enabled software adds AI functionality to an existing system after the fact. It can make information accessible more quickly and improve individual work steps, but the data model, the system boundaries and the periodic processes underneath remain unchanged. A batch-based ERP with an AI layer on top remains a batch-based ERP: the AI analyses the data it has access to, and in a batch system that means the most recent run. If that run took place last night, the AI works with yesterday's data; if the period has not been closed, it works with last month's.
On an AI-native platform, data, workflows, controls and AI form one operating model. Within the same system logic, the AI can read a document, apply the company's rules, execute the task, document the outcome and escalate the exception. The number of AI features says less than how deeply they are embedded in the system.
Where the AI sits decides who owns the number
The practical consequence is about ownership. A layer above the record can propose an entry, but it cannot own it: the posting still happens in the underlying system, under that system's cadence and controls, and the chain from a figure in a report back to the document and the decision behind it breaks at the handover between the two. An AI-native core owns the entry because it is the system of record. Capture, coding, matching and posting happen in one place, under one permissions model, and the audit trail records what the agent did, which rule it applied and who approved it. That is the condition under which a CFO can let an agent execute rather than merely suggest.
What an AI-native core requires
Four things distinguish the architecture. First, a shared data, control and permissions model, so that an agent is governed by the same roles, approval limits and segregation of duties as a person. Second, a clean separation between interpretative AI and deterministic posting logic: the agent classifies, matches and prepares, while rules, approvals and posting logic determine what is actually executed, so that the final entry is reproducible and auditable. Third, continuous processing, so that the data the AI works on is current rather than last night's batch. Fourth, an audit trail at the level of the individual action, including a confidence score on every automated posting that shows what an agent processed on its own and what it handed to a person.
Why the gap widens over time
In the early years an AI-enabled system can deliver results sooner, because it is simpler to deploy on top of what exists. As operational complexity grows, with more entities, more transactions and more exceptions, it plateaus: every new entity adds another instance to reconcile, every handover between the add-on and the record adds a place where traceability can break. An AI-native architecture improves with every document processed, every transaction coded and every exception resolved, because all of it happens inside one model. The upper limit of what AI in finance can achieve is set by the timeliness, structure and quality of the data it works on. Live Finance raises that limit; a batch system with an add-on caps it, however capable the add-on.
How to tell the two apart
Four questions settle it in a demo. Does the product require an underlying accounting system to function, or is it the accounting system? Does the AI post, within defined controls, or does it only suggest and hand over? Can a figure in a report be traced to its source without leaving the platform? Do the same permissions and approval limits govern the agent and the people? A product that keeps an existing system as its source of truth is an add-on, whatever its AI does on top.
How Aderis is built
Aderis was built AI-native from day one. Financial data, posting logic, AI agents, permissions and controls operate on the same core, the Platform Engine. Agents in Core Finance capture documents, code and post transactions, reconcile bank movements, follow up receivables and prepare payment runs; each transaction is recorded once and carried simultaneously into the statutory, tax, management and group ledgers. Where a case is unclear or exceeds an approval threshold, the agent stops and escalates it to the finance team. Every step is logged, and every number remains traceable to source.
Frequently asked questions
Is "AI-enabled" the same as "AI-native"?
No. AI-enabled means AI features added to an existing system; AI-native means AI inside the core that executes the work. The first changes what the software can show; the second changes what it does.
Can an AI add-on be enough?
For a single entity with standardised processes and a core system that is not itself the bottleneck, an add-on can deliver useful assistance. The limit is reached once finance has to run continuously across several entities, ledgers, currencies and systems.
Does AI-native mean the AI decides everything?
No. The finance team defines permissions, thresholds, approvals and escalation paths. Agents execute within that frame and escalate exceptions. People keep judgement, approval authority and accountability.
Does Aderis let a language model post entries?
Interpretative AI and deterministic accounting logic are kept separate. Agents classify, match and prepare; rules, approvals and posting logic limit what is executed. The result is reproducible and auditable.
