Skip to main content
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. Method coverage varies by interface and release; check your installed binding or service contract before implementing a workflow.
Use exact decimal-string methods and fields where your interface exposes them. For example, Node 1.35.1 provides payments.createExact, payments.createRefundExact, and amountExact, alongside numeric money fields. Do not parse exact values into a binary float before arithmetic.
For a runnable introduction, use the payment and refund quickstart. It verifies local record creation, retry identity, and refundable-balance guards, and explains the boundary between those records and an external payment provider.

​
General ledger

​
FX revaluation

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

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.
Per-item failures never abort the close. Read the per-step report rather than relying on an overall success flag.
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.
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.

​
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: Carts/checkout (10 endpoints) and backorders (5) round out the commerce side.
Last modified on September 20, 2026