What Is a Model
A model is a standardized accounting treatment for a class of economic activity.
It answers exactly one question:
When a specific economic event occurs, what is the correct GAAP accounting treatment?
The Definition
A model is:
- Triggered by an economic event — something that actually happened in the business
- Policy-driven — grounded in GAAP, not platform behavior
- Channel-agnostic — the same model applies whether the sale is Shopify, Amazon, or wholesale
- Reusable — one model supports many flows
A model is not a report, a workflow, or a system integration. It is the accounting rule itself.
What a Model Is Not
| This is NOT a model | This IS a model |
|---|---|
| Shopify order lifecycle | Revenue recognition on fulfillment |
| Amazon settlement processing | Cash settlement and clearing |
| Wholesale customer workflow | Customer prepayment received |
| Payroll run in Gusto | Payroll incurred and payroll paid |
| Inventory received in 3PL | Inventory receipt and capitalization |
System workflows and platform behaviors are flows. The accounting rule underlying them is the model.
What Makes a Model Complete
A model is only complete when it defines all of the following:
| Element | Description |
|---|---|
| Trigger event | The objective, observable economic event that activates the model |
| Preconditions | What must be true before this model applies |
| Journal entry logic | The debits, credits, and accounts affected |
| Timing rules | When recognition occurs — on what date, under what conditions |
| Account dependencies | What account structures must exist for the model to post correctly |
| Required dimensions | SKU, channel, location, customer, vendor, or other required attributes |
| Validation rules | What must be independently verifiable before posting |
| Reconciliation points | How the model ties to source systems and subledgers |
| Edge cases | Partials, reversals, timing mismatches, and missing support |
| Reversal logic | How the model unwinds when the underlying event is reversed |
A model missing any of these elements is incomplete. An incomplete model cannot be reliably used in a flow or validated in a control.
Why This Matters
Most accounting systems are built around:
- platforms (Shopify, Amazon, QuickBooks)
- transaction types (invoice, bill, payment)
- reports (P&L, balance sheet)
This creates three problems:
- Inconsistent timing — the same economic event (e.g., revenue recognition) gets treated differently depending on the channel
- No reusability — every new platform requires rebuilding the accounting logic from scratch
- Weak controls — without a defined model, there is nothing to validate against
Models solve all three by defining the accounting policy once, independent of any system.
One Model, Many Flows
Revenue Recognition Model
↓
┌─────────────────┬──────────────────┬──────────────────┐
Shopify Flow Amazon Flow Wholesale Flow
(Stripe settle) (Settlement RPT) (AR + deductions)
↓ ↓ ↓
Journal Entries Journal Entries Journal Entries
The model defines the rule. The flow applies it in a specific operational context.