Getting Started with Models
What Is a Model?
A model in this guide is a standardized accounting treatment for a class of economic activity that occurs inside a business.
Models answer the question:
When a specific economic event occurs, what is the correct GAAP accounting treatment?
A model defines the universal accounting rule.
It is policy-driven, channel-agnostic, and reusable across contexts.
Why Models Exist
Most accounting systems are built around:
- platforms
- transaction types
- reports
That creates duplication, inconsistent timing, and weak controls.
Models solve this by:
- standardizing accounting around economic events
- separating policy from implementation
- ensuring consistent GAAP treatment across channels
- enabling automation, validation, and repeatable execution
Without models:
- revenue timing becomes inconsistent
- inventory and COGS disconnect
- clearing accounts become unreliable
- every new channel creates new accounting chaos
Models are the foundation of a controlled, scalable accounting system.
What a Model Covers
Every model defines:
- the triggering event
- the accounting response
- the timing of recognition
- the balance sheet and P&L effect
- the governing GAAP policy
- the validation logic
- the expected reconciliation points
- the reversal or unwind logic
- the edge cases that affect treatment
What a Complete Model Must Contain
Every model must define:
| Element | Description |
|---|---|
| Trigger event | Objective, observable, and testable |
| Preconditions | What must be true before this model applies |
| Journal entry logic | Debits, credits, and affected accounts |
| Timing rules | When recognition occurs |
| Account dependencies | What account structures must exist |
| Required dimensions | SKU, channel, location, customer, vendor, etc. |
| Validation rules | What must be true for correctness |
| Reconciliation points | How the model ties to source systems and subledgers |
| Edge cases | Partials, reversals, timing mismatches, missing support |
| Reversal logic | How the model unwinds when the event is reversed |
If any of these are missing, the model is incomplete.
Model Categories
Models are organized around universal accounting systems:
| Category | What It Represents |
|---|---|
| Revenue | Revenue cycle from obligation through recognition |
| Inventory | Product lifecycle from receipt through cost recognition |
| Cash | Money movement, clearing, and settlement |
| Expenses | Operating costs, accruals, payables, and prepaids |
| Capital & Close | Financial structure, adjustments, and control processes |
Model Boundaries
Models operate at the level of a single economic event.
A model should:
- represent one atomic accounting concept
- not combine multiple events into one treatment
- remain universal across platforms and systems
Correct scope
- Prepayment received
- Revenue recognized on fulfillment
- Inventory received
- Accrued expense recorded
Incorrect scope
- Shopify order lifecycle
- Amazon settlement process
- Wholesale customer workflow
When models become too broad, accounting logic becomes ambiguous, validation weakens, and flows become inconsistent.
What Models Do Not Cover
Models do not define the system-specific implementation of accounting logic.
Flows define where the values come from, how those values are applied in a specific operational context, and how a platform or channel maps into the model.
| Models define... | Flows define... |
|---|---|
| Timing of recognition | Where the values come from |
| Fee treatment | Source system mechanics |
| Tax accounting | Channel-specific timing |
| Obligation accounting | Platform-specific exceptions |
| Recognition logic | Implementation details |
The model is the rule. The flow is the application.
Validation Philosophy
Every model must be independently verifiable.
Validation answers:
- Did the event actually occur?
- Are the amounts correct?
- Is the timing correct?
- Does the result tie to the rest of the system?
Examples:
- Revenue cannot be recognized without fulfillment
- COGS cannot be recognized without inventory movement
- Cash cannot be recorded without settlement
- Deferred revenue cannot be released without performance satisfaction
Validation is required for financial accuracy. It is not optional.
Common Failure Modes
Without a model-based system, businesses typically:
- recognize revenue on order date instead of fulfillment
- record payouts directly to revenue instead of clearing
- fail to reverse COGS on returns
- misclassify fees between COGS and operating expenses
- ignore timing differences between systems
- blend policy and implementation into one undocumented process
Models exist to eliminate these errors at the root level.
Mental Model
Operational Event → Model → Flow → Journal Entries
Example:
Order Fulfilled
↓
Revenue Recognition Model
↓
Shopify Flow / Amazon Flow / Wholesale Flow
↓
Journal Entries Posted
How to Use This Guide
- Start with the correct model category — Revenue, Inventory, Cash, Expenses, or Capital & Close
- Identify the scenario — Each model breaks the event into distinct scenarios (prepaid vs. AR, full vs. partial, accrued vs. invoiced)
- Read the accounting logic — Review affected accounts, debit/credit direction, recognition timing, validation rules, and reconciliation expectations
- Apply the policy — Each model is grounded in GAAP logic; document how the policy applies in your accounting manual and flow-specific context
- Go to the flow — Once the model is understood, move to the corresponding flow for platform-specific mappings, source system mechanics, and implementation details
Relationship Between Models and Flows
| Model | Flow |
|---|---|
| Defines the correct accounting rule | Applies the rule in a specific context |
| Universal | Context-specific |
| Policy-driven | Operationally implemented |
| Channel-agnostic | Channel-specific |
| One per economic event | Many per model |
Example:
| Model | Flow |
|---|---|
| What is the correct accounting for customer prepayment? | How does that model apply when payment is captured in Shopify and settled through Stripe? |
| What is the correct accounting for revenue recognition? | How does that model apply when a 3PL ships the order and the channel is Amazon? |
A flow is always grounded in a model.