The Problem With Calling Everything a 'Transaction'

Ask any accounting system to describe your business and it will tell you a list of debits and credits. Ask it why a payment came in late and it will shrug. Ask it which customers are likely to churn and it won't understand the question.

Traditional ERPs weren't built to reason about your business. They were built to record it.

That's a fine design for a world where humans do the reasoning. It's a problem in a world where AI is supposed to help.

The Flatness Problem

A traditional accounting system sees your business as a stream of transactions, each with a debit account, a credit account, an amount, and a date. This is double-entry bookkeeping — an accounting standard that's been around since the 15th century and is genuinely brilliant for what it does.

What it doesn't do is capture meaning.

When a $50,000 payment lands in your bank account, the accounting system records: Debit cash, credit accounts receivable. Full stop. It doesn't know this payment was from Acme Corp, that Acme Corp is a customer who signed a 24-month contract in January, that this is their third payment, or that their contract renews in December.

To answer "which customers are 90+ days overdue?" you need to join accounts receivable against customer records, filter by invoice date, exclude payments — a query that requires knowing the schema and writing SQL.

To answer "which customers are likely to renew?" the system has no answer at all.

What Richer Primitives Enable

If instead your system models the world as a graph of entities and relationships — organizations, people, agreements, artifacts, events — it can reason naturally.

• An invoice is an artifact created by a vendor, attached to a purchase order, governed by a contract
• A payment is an artifact that resolves that invoice, deposited into a bank account
• The vendor is an organization that has a customer_of relationship with you
• That relationship has attributes: payment terms, account manager, since date

Now the question "which customers are 90+ days overdue?" becomes: find all organizations with a customer_of relationship where there are open invoice artifacts past their due date. No custom SQL required.

More importantly, the AI can understand the question without being told the schema. It knows what an invoice is, what "overdue" means, what a customer relationship looks like.

Why This Matters for AI

Large language models are trained on human language, which describes the world in terms of entities and relationships. "Acme Corp owes us $50,000" is natural language. The AI understands it because it's the same structure as human thought.

"AR balance 12345 = 50000.00 USD" is machine language. The AI can process it, but it has to translate it back into meaning before it can reason about it.

An AI-native ERP should store data in a form that's already close to how the AI needs to think about it. Not flattened into debit/credit rows, but structured as the entities and relationships that make up your business.

This is one of the core design choices in BeanStack. We model your business as a graph of fundamental world primitives — a complete ontology of entity types that covers everything your business needs without custom configuration. Every financial document creates entities and relationships in this graph. The AI reasons over the graph directly.

The accounting layer still exists. Journal entries are still double-entry. But they're derived from a richer underlying model, not the model itself.

---

This is one post in an ongoing series on the design choices behind BeanStack.