> ## Documentation Index
> Fetch the complete documentation index at: https://docs.uselim.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Accounting = fn(events)

> The core philosophy behind lim: accounting as a pure function of business events.

# Accounting = fn(events)

lim is built on a simple idea: **accounting is a function**. Business events go in, journal entries come out. No batches, no month-end scrambles, no manual data entry.

```
journal_entries = f(business_events)
```

This is not a metaphor. It is the literal architecture of lim.

## The Problem with Traditional Accounting

Traditional accounting software treats the ledger as a database you write to manually. A human looks at a bank statement, decides which account to post to, types the numbers, and clicks save. This process has several problems:

1. **It's slow.** Entries are recorded days or weeks after the event.
2. **It's error-prone.** Humans transpose digits, pick wrong accounts, forget entries.
3. **It's batch-oriented.** Financial data is only "current" after monthly close.
4. **It doesn't scale.** More transactions = more human hours.
5. **It can't be automated.** AI agents can't operate legacy accounting software.

## The Functional Model

lim inverts this. Every business event -- a bank transaction, an invoice, a receipt -- is an **input** to a function. The function's output is a journal entry.

```
Event: { type: "bank_debit", counterparty: "AWS", amount: 11000, date: "2026-03-16" }
  ↓
f(event)
  ↓
Journal Entry:
  Debit  Communication     10,000
  Debit  Input VAT          1,000
  Credit Accounts payable  11,000
```

The function `f` is the [judgment engine](/agents/judgment-engine). It is deterministic when possible (rule match), probabilistic when necessary (AI inference), and always auditable.

### Properties of the Function

* **Deterministic where possible.** 95% of transactions hit a learned rule -- same input always produces same output.
* **Idempotent.** Processing the same event twice does not create duplicate entries.
* **Auditable.** Every judgment decision is logged: which step resolved it, what confidence level, who confirmed it.
* **Learning.** The function improves over time. Human corrections become rules.

## Event-Driven, Not Batch-Driven

In traditional accounting:

```
Day 1-30: Business happens
Day 31:   Accountant processes everything in a batch
Day 35:   Financial statements are "current" (already 5 days stale)
```

In lim:

```
Event occurs → Judgment engine fires → Journal entry created → Reports update
Latency: < 1 second
```

Financial reports (trial balance, P\&L, balance sheet, cash flow) are always live. There is no "close" step required to see current numbers -- though lim does support [period close](/concepts/compliance) for formal reporting.

## The Learning Flywheel

The functional model enables a powerful feedback loop:

```
┌─────────────────────────────────────────────┐
│  1. Event arrives                            │
│  2. Judgment engine classifies it            │
│     - Rule match (95% of events) → auto-post │
│     - AI inference (5%) → suggest to human   │
│  3. Human confirms or corrects               │
│  4. Correction becomes a new rule            │
│  5. Next similar event → rule match          │
└─────────────────────────────────────────────┘
```

Over time:

* Rule match rate increases (approaches 99%)
* AI inference rate decreases (approaches 0%)
* AI API costs approach zero
* Human involvement approaches zero

After 6 months of typical usage, a company with 200-500 monthly transactions should see fewer than 5 transactions per month requiring human input.

## Why This Matters for AI Agents

The functional model makes lim a natural fit for AI agents:

* **MCP tools map directly to functions.** `create_journal_entry`, `match_bank_transaction`, `generate_scenario` -- each is a pure function call.
* **Resources are read-only views.** Trial balance, accounts, journal entries -- agents can read the current state without side effects.
* **No UI required.** There is no "click this button, fill this form" workflow. Everything is an API call.
* **Agents improve the system.** When an AI agent processes a transaction and a human confirms it, that becomes a rule. The agent is training the system.

## Comparison

|                  | Traditional Accounting | lim                             |
| ---------------- | ---------------------- | ------------------------------- |
| Input method     | Manual data entry      | Events (automatic)              |
| Processing       | Batch (monthly)        | Real-time (\< 1 second)         |
| Classification   | Human judgment         | Rule → History → AI → Escalate  |
| Learning         | None                   | Corrections become rules        |
| Reports          | Stale until close      | Always live                     |
| AI agent support | None                   | Native (MCP + REST)             |
| Scaling          | More humans            | More rules (zero marginal cost) |