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

# Finance & Accounting

> General ledger, accounts payable and receivable, fixed assets, revenue recognition, and month-end close orchestration in the iCommerce engine.

# Finance & Accounting

The iCommerce engine carries a full double-entry finance layer alongside its commerce domains —
general ledger, AP, AR, fixed assets, and ASC 606-style revenue recognition — all available
over REST, the embedded accessor, both bindings, and as agent tools.

<Note>
  All monetary values cross the binding boundary as **exact decimal strings** (e.g. `"30.01"`),
  not floats. Do not parse them into a binary float before doing arithmetic.
</Note>

## General ledger

| Capability        | Detail                                         |
| ----------------- | ---------------------------------------------- |
| Journals          | Create, post, void, reverse                    |
| Reports           | Trial balance, balance sheet, income statement |
| Periods           | Open, close, lock, reopen                      |
| Chart of accounts | Full CRUD, with period helpers                 |

### FX revaluation

```
POST /gl/revalue
```

Idempotent unrealized gain/loss revaluation of foreign-currency accounts at the as-of rate,
posting a balanced adjusting entry to a configurable FX gain/loss account. Sign handling is
correct for credit-normal accounts. Available on both SQLite and PostgreSQL.

### GL auto-posting

Config-gated and **off by default**. When enabled, posted depreciation periods and recognized
revenue generate balanced, posted journal entries — depreciation expense to accumulated
depreciation, and deferred revenue to sales revenue.

## Month-end close orchestration

```
POST /gl/close-month
generalLedger().close_month(period_id, options)
```

One operation running depreciation posting → revenue recognition → FX revaluation → period
close. It supports **dry-run mode**, per-step skip flags, and returns a structured per-step
report with entry counts, totals, and warnings.

<Tip>
  Per-item failures never abort the close. Read the per-step report rather than relying on an
  overall success flag.
</Tip>

Exposed via HTTP, the Node binding (`generalLedger.closeMonth`), and the `close_month` CLI
tool. The admin console's Close page runs a dry-run report first and requires a typed
confirmation for the real close.

## Accounts payable

* **Bills** with AP aging and status filters.
* **Payments** with allocations, plus payment runs.
* **3-way match** — pure tolerance-based PO ↔ receipt ↔ bill matching at
  `GET /ap/bills/{id}/three-way-match`, computed on read.

## Accounts receivable

Aging, payment application, credit memos, write-offs, dunning, and statements. Collections
activities can be recorded and listed, with a dunning-due queue at `GET /ar/dunning/due`.

## Fixed assets

A full asset register: lifecycle `draft → in-service → disposed/written-off`, straight-line and
declining-balance depreciation schedules with an exact final-period plug, and disposal
gain/loss. Available on SQLite and PostgreSQL with embedded accessors.

## Revenue recognition

ASC 606-style: contracts, performance obligations with allocation validation, and ratable,
point-in-time, or milestone schedules with period recognition.

<Warning>
  Two correctness fixes landed here that change output. `generate_revenue_schedule` could emit a
  **negative final entry** — a spurious revenue reversal — when per-period rounding rounded up;
  periods are now capped at the remaining amount. And `run_period_close` failed on contra-normal
  income-statement balances, such as a net FX gain on an expense-type gain/loss account; closing
  lines are now sign-aware, and periods with offsetting activity but zero net income close
  instead of erroring.

  Both were found by property-based tests. If you reconciled against earlier output, re-check it.
</Warning>

## Cycle counts

Full workflow `draft → in-progress → completed`, with transactional variance application to
location inventory and `cycle_count` movement audit records.

## Domain events

Ten finance events are webhook-subscribable:

* Fixed asset placed in service, disposed, written off
* Depreciation posted
* Revenue recognized
* Revenue contract completed
* Cycle count completed
* 3-way-match variance detected
* FX revaluation posted
* Month-end close completed

## Purchase-order state machine

`PurchaseOrderStatus::can_transition_to` plus `validate()` are enforced in the store — illegal
transitions now return validation errors rather than silently applying.

Terminal-state guards also apply to transfer-order and inbound-shipment cancellation on both
backends: received or already-cancelled documents can no longer be cancelled.

## Coverage

Roughly **140 REST endpoints** cover this surface, all documented in OpenAPI with tags and
validated by the spec test suite:

| Domain                                           | Endpoints |
| ------------------------------------------------ | --------- |
| General ledger                                   | 18        |
| Purchase orders + suppliers                      | 18        |
| Warehouse (locations, adjust/move, cycle counts) | 18        |
| Quality (inspections, NCRs, holds)               | 15        |
| Accounts payable                                 | 14        |
| Fulfillment (waves, pick/pack/ship, cartons)     | 13        |
| Work orders                                      | 13        |
| Accounts receivable                              | 12        |
| Receiving (receipts, put-away)                   | 12        |
| Fixed assets                                     | 10        |
| Lots                                             | 9         |
| BOM                                              | 8         |
| Serials                                          | 8         |
| Revenue recognition                              | 8         |

Carts/checkout (10 endpoints) and backorders (5) round out the commerce side.

## Related

* [API Hardening](/stateset-icommerce/stateset-icommerce-api-hardening) — auth, idempotency, pagination
* [Backup & Restore](/stateset-icommerce/stateset-icommerce-backup-restore)
* [Bindings](/stateset-icommerce/stateset-icommerce-bindings)