Most ERPs store the current state of your business. SimpleGrid stores everything that ever happened. That is not a minor technical difference. It is the reason we can deploy in days, change rules without breaking anything, and give you an audit trail that does not need to be "turned on."
The concept is called event sourcing. Here is how it works, in factory terms.
The traditional approach: storing state
In a typical ERP, your Purchase Order PO-122 is a row in a database. That row says: Vendor = Midwest Supply. Quantity Ordered = 500. Quantity Received = 300. Status = Partially Received.
When the warehouse manager receives another 100 units, the system updates the row: Quantity Received = 400. The old value (300) is gone. Overwritten. If you want to know what happened between 300 and 400, when it happened, who did it, you need an audit log. A separate system that somebody remembered to turn on.
Most audit logs are incomplete. Some ERPs do not log everything. Some log timestamps but not actors. Some do not log field-level changes. You end up reconstructing history from fragments, or from the warehouse manager's memory.
The event sourcing approach: storing everything
In SimpleGrid, PO-122 does not have a "quantity received" field that gets updated. Instead, the system stores every event that happened to PO-122:
The current state, "400 received out of 500 ordered," is calculated by reading the events. Not stored directly. Calculated.
This might seem like a small distinction. It changes everything.
What you get for free
Complete audit trail. Not a log that someone turned on. The events ARE the data. Every action, every actor, every timestamp. Immutable. Append-only. Can never be deleted or modified. If a regulator asks "who received what, when, and how much?" the answer is the event ledger itself.
Time travel. Want to know what your inventory looked like on February 1st? Read the events up to that date. Calculate the state at that point. No separate snapshot needed. No "as-of" reports that someone has to build. The ledger contains the complete history by definition.
Reconciliation is eliminated. In a traditional ERP, the warehouse says 400 received, the vendor says 500 delivered, and someone spends 2 hours reconciling. In event sourcing, every receipt is a distinct event with a timestamp, a quantity, and an actor. There is nothing to reconcile. There is only what happened.
Dashboards can be rebuilt. Your "revenue by month" dashboard is not stored separately. It is a projection, a view calculated from the event ledger. If the calculation was wrong, fix the formula and reproject. The underlying events have not changed. The source data is always intact.
How this works on the factory floor
The warehouse manager types: "Received 200 sheets of 16-gauge steel from Midwest Supply."
Here is what happens in milliseconds:
1. System looks up the open PO from Midwest Supply for 16-gauge steel.
2. Checks the current state: PO is in state "Ordered." Transition "receive" exists.
3. Permission check: does this user have the warehouse role? Yes.
4. Rule check: 200 is less than or equal to ordered quantity? Yes.
5. State update: PO moves to "Partially Received."
6. Event written: { type: PartialReceive, entity: PO-4521, qty: 200, actor: warehouse_mgr, timestamp: now }
7. Downstream triggers fire: inventory increases by 200. Running rate recalculates. Journal entry auto-generated.
The warehouse manager sees: "200 sheets received."
Seven steps. All from one event. All in milliseconds. And that event, step 6, is permanent. It will exist in the ledger forever. It can never be modified. It is the source of truth.
Why this makes fast deployment possible
Traditional ERPs need months because every piece of business logic is application code. Change the logic, redeploy the application.
In an event-sourced, configuration-driven system, the logic lives in tables. The engine reads the rules, processes events, and writes to the ledger. The rules can change without touching the engine. The engine is built once and shared by every client. The full picture: each client runs from their own SG Schema, the operational blueprint our AI writes during onboarding.
When we deploy for a new client, we are not building an application. We are writing the SG Schema that describes their business. The engine already exists. The ledger structure already exists. The projection layer already exists. We are configuring, not coding.
That is why it takes days instead of 18 months.
The real-world test
Next time you use your current system, try to answer this question: "Show me every action that happened to Purchase Order 122, in order, with who did it and when."
If the answer is complete, timestamped, and immutable, your system stores events.
If the answer is partial, reconstructed from audit logs, or requires a report that someone has to run, your system stores state. And you are missing data every day.
SimpleGrid is built on event sourcing. Every action, every actor, every timestamp. Immutable. Permanent. No audit trail to "turn on." It is the architecture.