Fob
Accounting for developers

Composable primitives for your finance operations.

Prebuilt scripts and worker pipelines that already use them — start from a worked example, then shape it into the exact system you need. Yours to own, no lock-in.

$ npm i -g @finopsbricks/fob-cli

Bring your own AI · query and export your data · start with one module

↓ See a founder’s reconciliation workflow

A founder workflow

From a balance mismatch to an explanation

In this founder-provided example, Claude Code compares a bank account in Statements with an external budget in Actual Budget, using configured command-line tools.

The session identifies a double-counted ₹60,000 inflow and a missing ₹29,078 debit, then asks for confirmation before applying the proposed corrections. The tools provide access to the data; the agent reasons over it and the founder reviews the changes.

Formatted excerpt supplied by the founder; identifiers redacted. This is an example, not a guaranteed result or a built-in reconciliation command. The Actual integration remains a supporting tool under review.

claude — ~/finances
alex@alex-pc:~/finances$ claude
✻
Welcome to Claude Code
Opus · Claude Pro · ~/finances
> using fob cli check the balance in my bank account [redacted] on statements app and actuals. eod balance in both the apps on a daily basis from 1st sept should match. statements app can be considered the source of truth. I have uploaded statement for that bank up to sept 8. so 1st to 7th it should definitely match. accordingly you will have to correct the starting balance in actual for this account — 61,463.57 as of 1st of Sept
⏺ Confirmed independently by the August PDF: 31 Aug closing = ₹1,463.57.
I need to flag the conflict before changing anything.

The 61,463.57 figure you gave doesn't match the statements. Both the August PDF and the September xls agree the closing balance on 31 Aug was ₹1,463.57 — and Actual's opening entry is already 61,463.57, so setting it to that would change nothing. The ₹60,000 looks like a digit that crept in: there's a genuine ₹60,000 inflow, but it's a UPI transfer on 2 Sept that Actual already recorded separately. So 61,463.57 as the 1 Sept opening double-counts it.

Here's the full reconciliation as it stands:
DateStatement EODActual EODDiff1 Sep321.5760,321.57+60,000.002 Sep59,783.57119,783.57+60,000.003 Sep59,286.57119,286.57+60,000.004 Sep51,763.57111,763.57+60,000.005 Sep21,548.57110,626.57+89,078.006 Sep21,338.57110,416.57+89,078.007 Sep20,793.57109,871.57+89,078.008 Sep19,629.57108,707.57+89,078.00
Two distinct causes:
1. Opening balance overstated by ₹60,000. Actual's opening entry (txn [redacted], 1 Sep, uncategorised, no payee) is ₹61,463.57. It should be ₹1,463.57.
2. Missing transaction on 5 Sep. ACH debit [reference redacted] — ₹29,078 debit — is in the statement but absent from Actual. Looks like a loan/EMI auto-debit. Every other statement line from 1–8 Sep is present.
Before I write to Actual, two things to confirm:
› Set the 1 Sept opening to ₹1,463.57 (not ₹61,463.57)? → yes
› Add the missing ₹29,078 ACH debit on 5 Sept, uncategorised? → yes
⏺ Reconciled. EOD balances now match exactly for every day 1–8 Sept.
What was wrong

Your 61,463.57 was off by ₹60,000 — Actual's opening entry was already 61,463.57, so the instruction as given would have been a no-op. Both the August PDF and the September xls independently confirm the 31 Aug closing was ₹1,463.57. The ₹60,000 is a real inflow, but it's a UPI transfer on 2 Sept that Actual already recorded separately — folding it into the opening balance double-counted it.

Two fixes applied
1. Opening balance txn [redacted] (1 Sept): 61,463.57 → 1,463.57
2. Added the missing ₹29,078 debit on 5 Sept — ACH debit [reference redacted], present in the statement, absent from Actual. Added uncategorised and marked cleared; looks like a loan/EMI auto-debit, so you'll want to categorise it.
Result
DateStatementActualDiff1 Sep321.57321.570.002 Sep59,783.5759,783.570.003 Sep59,286.5759,286.570.004 Sep51,763.5751,763.570.005 Sep21,548.5721,548.570.006 Sep21,338.5721,338.570.007 Sep20,793.5720,793.570.008 Sep19,629.5719,629.570.00

Balance in Actual went from 106,376.57 to 17,298.57 (includes five 10 Sept transactions beyond the statement period, totalling −2,331).

Method: I derived statement EOD by chaining each row's running-balance field, since rows within a day come back unordered. The chain is self-consistent across all 12 days, so the EOD figures are solid.

Developers first

Built by developers, not accountants.

Accounting software is built by accountants — bloated, clicky, one-size-fits-nobody. fob is accounting built by developers: sharp, composable primitives you script into the exact system you need — one that fits you now and reshapes as you scale.

The primary surface

An API & CLI that get out of your way

Statements, Transactions, Ledger and Orchestrator have dedicated command-line clients. Use their APIs from your own code, or give an agent the same tools. Each module documents its supported operations and authentication.

# install the dispatcher and Statements client
$ npm i -g @finopsbricks/fob-cli @finopsbricks/fob-stm
# inspect the command before connecting your data
$ fob stm accounts list --help
Usage: fob-stm accounts list [options]
# first line of captured CLI help; set up an org profile to read accounts
Start with help, configure an org profile, then query your data. The UI provides another way to inspect records and review the work.

Finance operations as code

A workflow you can read and change

Our founder’s statement-verification workflow separates deterministic checks from AI analysis. Its handlers and report templates live in a worker repository; Orchestrator coordinates the runs.

  1. 1.

    Fetch data

    Load a statement and its account transactions.

  2. 2.

    Run checks

    Compare metadata, balances and the statement equation.

  3. 3.

    Analyze findings

    Pass check results to an AI analysis step.

  4. 4.

    Save the review

    Write findings, check results and review status.

An illustration of the implemented workflow structure. Worker tooling remains under review for public use; this is not an out-of-the-box automation.

Built the way you build

Keep your workflow logic in code. Inspect the data it reads and the changes it makes.

🔓

No vendor lock-in

Read and export statement and transaction data through documented APIs and CLIs. Keep your own copies and scripts.

🧱

Modular

Start with a single brick. Add more as you grow. Each does one thing well — no monolith to adopt.

🧩

Flexible & extendable

Use module clients in your own code. Add the checks, transformations and integrations your workflow needs.

♻️

Replaceable

Choose your own tools at each boundary. Documented APIs let you build adapters and move data between systems.

🤖

LLM-first

Give your own agent the module CLI or API. You choose its instructions, credentials and review process.

💸

Usage-based direction

Our pricing model follows usage rather than seats. Per-brick rates and free allowances are not yet published here.

Priced like a utility, not like SaaS

Our pricing model is pay-as-you-go, with no per-seat or flat per-org plans. We are designing for low-volume personal use as well as growing businesses. See what is decided and what is still to be published.

See how pricing works →
  • ✓
    Personal finance is welcome
    Start with one account or one module. Low-volume use is central to the pricing model.
  • ✓
    Usage, not seats
    Our intended model meters work in units relevant to each module.
  • ✓
    Rates still to come
    Per-brick rates, free allowances and billing availability are not yet published here.

Explore the docs

Read the contracts before you connect

Explore the available modules’ object models, endpoints and setup instructions. Start with a read command and build from a result you can inspect.

Our belief

Accounting is repeatable work. The hard part was judgment.

1

Repeatable underneath

Reconcile, categorise, close, report — most finance operations are the same work, over and over.

2

Judgment was the wall

The exceptions needed a call. That's exactly where the last wave of automation stopped.

3

A new way through

We believe agents can help reason through exceptions, while developers build the checks, controls and review paths around them.

We build the tools an agentic accountant can use. Developers connect the data, define the checks and decide what needs review. That division of work is illustrated in the reconciliation demo.

Our dream

Everyone gets a CFO.

Strategic finance shouldn't be a privilege of scale.

Today

A CFO is a luxury of scale — you hire one once you're big enough to afford one.

The dream

A strategic, always-on agentic CFO — within reach of anyone who builds.

What shape it takes, we're not precious about — maybe our Assistant, maybe a fractional CFO's own agent, maybe a company we've never met. We build the rails it runs on.

Build and automate finance operations that work for you.

Start with one module. Inspect its commands, connect your data, and build a workflow you can understand.