AI Routing Inside an ERP-Adjacent Platform

The question is why a bank statement import demo matters beyond the import itself. On the surface, it is a product walkthrough: upload a file, parse rows, categorize transactions, show results. But deeper inside the build process, this kind of demo reveals whether the platform is becoming a system or remaining a collection of screens.

What is at stake is not only feature completion. It is operational trust. An ERP-adjacent platform sits near ledgers, vendors, tenant records, audit trails, and human review loops. If the import pipeline works but tenant isolation is weak, the system is not ready. If AI categorization works but cannot be routed, inspected, or constrained, it becomes a liability. If operators cannot see what happened, every exception becomes a support ticket.

From first principles, the platform has to answer a few simple questions. Who is the tenant? What data came in? Which process touched it? Which AI skill was invoked? What did it decide? What can an operator correct without engineering help? The recent Clearova demo was useful because it moved through these layers in sequence: tenant onboarding, operator tooling, AI skill configuration, schema inspection, and a live bank statement import.

The platform is separating tenant experience from operator control

The walkthrough covered both sides of the product: what a tenant sees and what an operator controls. That distinction matters.

Tenant-facing software should feel narrow and task-specific. Users should not need to understand platform internals to import a statement, manage vendors, or review general ledger activity. Operator-facing software has the opposite requirement. It needs to expose enough of the system to diagnose issues without making every diagnosis a database exercise.

The operator panel appears to be moving in that direction. The demo included tenant onboarding, theme controls, preference management, AI skill configuration, and database schema inspection. This is not just administration. It is the control surface for a multi-tenant financial workflow product.

A few examples stood out:

Tenant onboarding can be managed through the platform rather than manual setup.
Theme and color preferences can be previewed and saved immediately.
Team and holiday themes are supported, which suggests a broader preference system rather than hardcoded styling.
A GL audit report view has been added, giving operators and users a structured way to inspect ledger-related activity.

None of these pieces are individually complex in isolation. Together, they show a platform starting to treat configuration, review, and visibility as first-class concerns.

AI profiles are becoming operational skills

One of the most important design choices in the demo was the language shift from AI profiles to skills.

That change is more than cosmetic. A profile sounds like a static configuration. A skill implies a callable capability with boundaries, parameters, and a purpose. In the demo, each skill had its own model name, temperature, max token limit, system prompt, API key, and router eligibility setting.

That structure matters because ERP-adjacent AI should not be one general assistant with broad access. It should be a set of constrained capabilities:

A bank statement importer skill can parse and categorize transactions.
A support assistant skill can answer product questions.
A coding or internal diagnostic skill can be system-only.
A reconciliation skill can operate under different rules than a vendor-management skill.

The router-eligible toggle is especially important. Skills that are not marked as router-eligible remain system-only. That means they can be invoked by defined workflows but not selected freely by a general router. The bank statement importer, for example, does not need to be available as a conversational destination. It needs to run when the import pipeline calls it.

This is the right direction. AI in financial systems should be routed by context, not enthusiasm. The platform should know when a skill is allowed to participate, what input it receives, and what output shape is expected.

The import pipeline is the test of the architecture

The live bank statement import was the most revealing part of the session. It connected the platform layers in a way that static screens cannot.

A file was imported. Transactions were created. AI categorization began after a visible delay. The system processed transactions in real time. Some records were categorized, while at least one transaction remained uncategorized and was flagged as needing work.

That visible delay is worth noting. In many demos, latency is hidden or edited out. Here, the delay showed the real behavior of the system. For an operator, that is useful. It suggests the need for clear intermediate states:

File received
Rows parsed
Transactions created
AI categorization pending
AI categorization complete
Exceptions require review

Without those states, users interpret delay as failure. With them, delay becomes part of the workflow.

The import also surfaced a duplicate key error. The issue was traced to tenant ID isolation logic and resolved during the session. That is exactly the kind of bug a live import should expose.

In a multi-tenant platform, duplicate keys are rarely just duplicate keys. They often reveal assumptions about identity, scope, or record creation. A transaction identifier that is unique for one tenant may not be unique across the system. A vendor name may repeat across tenants. A bank account may produce similar row structures. The schema has to encode isolation deliberately.

The fact that the bug was found and fixed mid-session is less important than what it showed: the import pipeline is now real enough to create real integration failures.

Schema visibility is becoming a product capability

The demo also included a database schema viewer. For an early platform, this can look like an internal convenience. Over time, it can become much more.

Schema visibility helps engineering move faster, but it also helps operators understand the shape of the system. In ERP-adjacent workflows, many support questions are really data lineage questions:

Was this transaction imported or manually created?
Which tenant owns this record?
Did categorization run?
Was the category AI-generated or human-reviewed?
Which vendor record is linked?
What changed after import?

A schema viewer does not answer all of these by itself. But it reflects an important posture: the system should be inspectable.

That same posture applies to the GL audit report. Ledger-adjacent products need auditability early. Reports and schema tools are not afterthoughts. They are how the platform earns permission to automate more of the workflow.

Vendor management is moving to the right level of abstraction

The 1099 vendor management page is being reworked because the current design is too manual. The planned direction is vendor-record-level management.

That is a meaningful correction. Tax and vendor workflows should not be managed only as page-level forms or isolated tasks. They need to attach to durable vendor records that accumulate state over time.

A vendor record can become the home for:

W-9 or 1099 status
Tax classification
Payment history
Address and identity changes
Review notes
Exceptions
Required follow-up

This is the difference between completing a form and maintaining an operational object. The former helps a user get through a screen. The latter supports repeatable work across accounting periods.

For a platform near ERP workflows, durable objects matter. Transactions, vendors, tenants, bank accounts, statements, categories, and audit events all need stable identities. AI can assist around those objects, but it should not replace the need for clear records.

Operator tooling should expose unfinished states

Several issues surfaced during the demo: UI gaps, an uncategorized transaction state, and the duplicate key error. These are not merely defects. They are signals about what the operator tooling needs to expose.

A mature import workflow does not assume everything completes cleanly. It assumes partial completion and makes it manageable. That means the interface should help operators answer:

Which imports are still processing?
Which transactions failed categorization?
Which errors are tenant-specific?
Which records were skipped because of duplication?
Which AI skill handled the transaction?
Can the operator retry only the failed portion?

The goal is not to eliminate every exception. The goal is to keep exceptions bounded, visible, and recoverable.

This is where the AI skill architecture and the import pipeline meet. If a transaction is uncategorized, the platform should eventually show whether the skill declined, timed out, returned invalid output, or lacked enough context. Each case suggests a different next action.

The unfinished prompt engineering segment may be the next lever

The session ended abruptly just as the presenter was about to walk through a prompt engineering approach using two separate AI coding assistant sessions in sequence.

That missed segment matters because it points to the build process behind the product. The platform is not only using AI inside the application. AI is also being used to help construct, debug, and refine the application itself.

The two-session approach suggests a useful pattern: separate generation from review, or implementation from critique. One assistant can produce a change. Another can inspect it against architecture, tenant isolation, schema consistency, or UI behavior. Used carefully, this creates a lightweight internal review loop.

For a system like this, the same principle applies at runtime. One skill may categorize. Another may validate. A deterministic rule may check both. The broader lesson is that AI should rarely be the only step in a financial workflow. It should be one participant in a controlled sequence.

What this demo showed

Ultimately, the demo showed a platform crossing from interface assembly into system behavior. The important progress was not that a bank statement could be uploaded. It was that the upload touched tenant identity, schema design, AI skill routing, categorization state, operator visibility, and error handling.

What this means is that the next phase is less about adding isolated features and more about tightening the seams. Tenant isolation needs to be consistently encoded. AI skills need clear eligibility and observability. Import states need to be visible. Vendor management needs to center on durable records. Audit views need to keep expanding from reports into traceability.

The takeaway is simple: in ERP-adjacent software, working once is not the standard. Working visibly, repeatably, and within the right boundaries is the standard. This demo showed that the core functionality is now real enough to test those boundaries. That is where the serious product work begins.