FMS - finance system of record
Agents read the books.
They don't post them.
FMS is a governed finance system of record for an agentic stack. It turns operational evidence from SCM, WMS and RMS into controlled accounting - agents read the books and recommend, but only a person posts.
- entity
- SPL-IN
- ledger
- primary
- period
- 2026-07
lifecycle
- DRAFT
- SUBMITTED
- APPROVED
- POSTED
maker submits, a different approver approves, only then it posts - the approver is never the maker.
in active build: GL posting runs in-memory today and resets on restart. Being hardened onto persistence.
The finance surface
The whole finance surface, in plain terms.
This is what FMS covers, one short line each. The foundations are durable and survive a restart; the transactional ledger runs in memory today and is being hardened - each tile says which it is.
Durable
Chart of accounts
Hierarchical accounts with type, normal balance, posting state and FS / tax mappings. A starter SPL-IN / INR seed imports 18 accounts.
Durable
Finance masters
Legal entity, ledger, fiscal period, dimensions, tax codes, bank accounts and vendor / customer accounting profiles, with full CRUD and audit.
Durable
Fixed-asset accounting
Capitalization, straight-line and WDV depreciation runs, disposal, impairment and the matching GL reconciliation lines.
Durable
Source-system connectors
Real HTTP clients to SCM, WMS and RMS on OAuth client-credentials, each pull saved as a fingerprinted evidence record.
In active build
GL, AP, AR & cash
The posting lifecycle and trial balance, 2 and 3-way match, aging and bank reconciliation. Runs end to end in a session, in memory today.
In active build
Tax, budget & close
GST and TDS registers, budgeting and forecasting, and the period-close checklist. Works in-session, being hardened onto persistence.
In active build
Reporting
Financial statements and an operational pack. Report snapshots do persist, with SHA-256 data-version fingerprints.
The journal lifecycle
Every entry moves through maker-checker.
A journal never posts itself. A maker writes balanced lines, a different approver signs off, and only then does it post - immutable, with corrections booked as explicit reversals. Agents can read every step and recommend, but no tool posts the books.
01
Draft
Maker writes balanced lines
02
Submitted
Sent for approval
03
Approved
A different approver signs off
04
Posted
Immutable in the ledger
05
Reversed / adjusted
Corrections stay explicit
How FMS fits
Downstream of operations. Owner of the books.
- Evidence from SCM, WMS and RMS, pulled over authenticated calls
- A persisted, fingerprinted record behind every pull
- Arin can read the books and recommend, but cannot post
Operations to booksAgent-safe by design
Agents read and recommend. They cannot post.
- Read resources explain statements, snapshots and close checklists
- Action tools are approval-gated, idempotent and audited
- journal.post, payment.release and period.unlock are not in the catalog
Read and recommendWhere it sits
Where FMS sits, honestly.
FMS is nowhere near mature finance suites on breadth or maturity, and it is not trying to be. It occupies a different seat: the governed accounting brain of an agent-operated product stack. Each of these tools has a real, earned place.
FMS is early, pre-revenue and local-dev only. NetSuite, Sage Intacct, SAP, Oracle, QuickBooks and Xero are production systems with breadth and coverage FMS does not have and is not chasing. What FMS owns is one thing the others were not built around: books an agent can drive but never bypass.
Under the hood
How the governed books actually hold together.
The story above is the plain version. For evaluators, here is the depth - the frontend is React, the backend Spring Boot on Java 17, and FMS is a pure resource server that validates ICE-minted RS256 tokens.
The governed journal
The controls are not policy on a wiki - they are how the ledger is built. Postings move through separated approval, posted lines are immutable, and periods lock.
Maker-checker
Every posting moves DRAFT -> SUBMITTED -> APPROVED -> POSTED. The approver is never the maker.
Immutable posted journals
A POSTED line is never edited. Corrections are explicit REVERSED or ADJUSTED entries - the history stays intact.
Period locks
PeriodLockLevel gates who can post into a period; close applies the lock. Budget versions carry their own status.
Scope-aware authorization
@PreAuthorize enforces ICE-issued scopes across 14 controllers. No login form - FMS validates RS256 tokens against ICE JWKS.
Scope-gated by ICE
FMS has no login form. It validates ICE-minted RS256 tokens against ICE JWKS and authorizes on the scopes ICE issued, enforced by @PreAuthorize across 14 controllers.
Agents cannot post
The MCP surface Arin drives is split in two. Read resources explain and never change. Action tools are approval-gated, idempotent and audited. The tools that would mutate the ledger are deliberately absent from the catalog.
read resources - explain, never change
- fms://close/checklists
- fms://reports/financial-statements
- fms://reports/operational-pack
- fms://reports/snapshots
- fms://budget/arin-constraints
action tools - approval-gated, idempotent, audited
- close.stage.complete
- close.lock.apply
- report.snapshot.create
- budget.restriction.check
not in the catalog - by design
- journal.post
- payment.release
- period.unlock
Source evidence, never shared tables
FMS pulls evidence from SCM, WMS and RMS over real HTTP with ICE-minted OAuth client-credentials tokens, persists a fingerprinted SourceEvidenceRecord for every pull, and fails closed on unapproved source state. No shared database tables.
Private - early access
See the governed books, end to end.
FMS is early and private - local-dev only, no self-serve sign-up, no customers yet. The foundations are live and the governed loop runs end to end today. Tell us about your stack and we will walk you through the real, approval-gated, agent-safe flow.