Comparisons · PG-14 · Campfire
Ledgerbook AI vs Campfire
One is an AI-native ERP that owns its own ledger. One is the accounting data layer any application can read. Most teams evaluating both are actually answering a different question first. Facts captured 2026-09-22, sourced below.
Last verified 2026-09-22 · re-verified quarterly and within 14 days of a launch · corrections → contact
Campfire is an AI-native ERP for high-growth technology companies — its own general ledger, subledgers for revenue, prepaids, fixed assets and leases, multi-entity and multi-book accounting, and an AI agent, Ember, running on a proprietary model the company calls Accounting Intelligence (their product pages, fetched 2026-09-22). Ledgerbook is not an ERP and does not try to be: it is the accounting data layer beneath whatever systems a group already runs, chain-hashed by default, with typed corrections, a governed agent write surface and deployment that includes self-host and air-gap. The honest framing is that these are rarely a head-to-head purchase. Campfire replaces the system your accounting team works in. Ledgerbook is the book of record several such systems feed. Below we concede where Campfire is the better answer, then compare on facts.
Verified 2026-09-22 · sources: campfire.ai product, changelog and blog pages · campfire.ai/llms.txt · llms.campfire.ai · dossier m8, same date
The question before the comparison
Most finance stacks answer "what is already determined for this period?" in one of three ways. They are not the same trade.
| ERP that owns the ledger Campfire, Rillet, NetSuite | Planning tool on exports EPM / FP&A class | Ledger of record as a layer Ledgerbook AI | |
|---|---|---|---|
| Where the schedules live | Inside the ERP's own subledgers | Nowhere — the tool receives a trial balance, so contracted and scheduled amounts arrive as assumptions | In the ledger of record, readable by every application above it — recorded from the owning subledger, never computed here FR-240/241 · PH-1 |
| Who can read them | That ERP, and tools it chooses to expose them to | The planning tool, at export granularity | Any credentialed reader over REST, GraphQL, CLI or MCP — row-level scoped FR-803 · PH-1 |
| If you change ERP | The forward view leaves with it | Re-mapped to the new export | The book of record and its history stay where they are NG-8 · PH-1 |
| Coverage | One entity estate, one vendor | Whatever feeds it | Several source systems consolidated into one auditable book FR-128–134 · PH-1 |
One distinction in our column is load-bearing and we keep it explicit everywhere: the ledger records committed positions and relates them to the contract, bill, asset or lease behind them. It does not compute them. Amortisation, depreciation and revenue-recognition schedules are the owning subledger's arithmetic, and we say so rather than implying we derive them. See the committed-schedule question below.
Side by side
| Dimension | Campfire | Ledgerbook AI |
|---|---|---|
| Deployment | Cloud-only SaaS; no self-host, BYOC or air-gap option published. SOC 1 and SOC 2 Type 1 and Type 2 certified, encryption at rest and in transit, 1,200-plus granular permissions. their product and security copy, 2026-09-22 | Self-host and air-gap first-class: single node, basic HA, offline bundle with zero egress. NFR-6 · PH-1 Embedded class and multi-region residency are Roadmap. SOC 2 Type II is targeted inside PH-2 and is not certified today. |
| Immutability & corrections | Audit trail on every action, attributed to the acting user or agent; human-in-the-loop review before any AI-proposed entry posts; configurable confidence thresholds for what auto-applies. No cryptographic chain or third-party-verifiable proof object published. their Ember page, 2026-09-22 | Chain hash on every Final entry, on by default and not disableable by writers; balances derived, never mutated; corrections only as typed reversing, adjusting or restating entries; one-way finalization. FR-118/119/123–125/205/214 · PH-1 |
| Agent write path (MCP) | Inbound. An MCP store of OAuth connectors, plus any hosted MCP server added by URL; Ember reads those systems and acts inside Campfire. No published MCP server exposes Campfire's ledger to an external agent — their launch post argues explicitly against routing AI through an external tool with write access. their MCP store post, 2026-05-14, fetched 2026-09-22 | Outbound. The ledger is the MCP server, running inside your deployment, air-gap included, with the same semantics and error taxonomy as HTTP. Agents may read and propose; they cannot approve, finalize or correct, enforced at the credential. T2/T3 tiers are Roadmap. FR-220/343 · PH-1 |
| Accounting depth | Own GL with multi-entity consolidation, multi-book accounting, 180-plus currencies, ASC 606 revenue automation across subscription, usage-based and hybrid models, ASC 842 leases, fixed assets, prepaids, close checklists and flux analysis. their product pages and changelog, 2026-09-22 | Multi-dimensional accounts and a dimension registry; Scenario as a native axis (plan, budget, forecast and simulation in the same ledger, per-scenario double-entry); Book axis for valuation bases; multi-entity intercompany as explicit paired entries; posted FX with the rate locked at posting. FR-102/103/128–134/300–345 · PH-1 Compliance packs are Roadmap. We do not ship subledgers — that is the ERP's job. |
| Forward view | Forecast (launched 2026-09-18): a near-term income statement in three layers — Actuals, plus Committed from the four subledgers shown as if posted, plus Estimates from Ember for the remainder. Percent committed is shown per month until close reaches 100%; estimates are advisory and nothing posts to the GL automatically. their launch post, fetched 2026-09-22 | Every composed and variance read returns a maturity object per slice — final and provisional amounts, provisional percentage, age of the oldest provisional entry and reconciliation state FR-350 · PH-1. The server-computed forecast_ready gate that fails closed and names its unsatisfied conditions is Roadmap FR-355. Committed positions are recorded from the owning subledger as SCHEDULED entries bound to the contract, bill, asset or lease behind them, and reported as the committed band of the same maturity object — so a planning tool, an agent or an auditor reads the same forward view, not an export of it. FR-240/241 · PH-1 |
| Provenance / audit export | Full audit trail per action with source attribution; every AI answer links back to source GL accounts, transactions and documents; reports export to spreadsheet formats. No standards-based process-mining export published. their Ember page, 2026-09-22 | OCEL 2.1 JSON export plus an independently runnable verifier; a provenance event on every mutation carrying who, when, through which surface and under which policy. Bundled export formats and packaged evidence sets are Roadmap. FR-905/121 · PH-1 |
| Commercial shape | Quote-led, no public pricing page. Priced on features and complexity rather than seats; factors named as entity count, transaction volume, revenue-model complexity and integration count; implementation by their own team, typically 4–8 weeks, no external SI required. Funding $103.5M. their agent-hub pricing page, 2026-09-22 | Open-core, source-available stance (licence text to publish before commercial launch); quote-led enterprise, no per-transaction metering on the base. OI-12/19 |
Sources: campfire.ai · /ember · /core-accounting · /changelog · the Forecast launch post · the MCP store post · campfire.ai/llms.txt · llms.campfire.ai — all fetched 2026-09-22; funding from dossier 14 (2026-09-19). For our column: product specification, PH-1 and Roadmap as tagged.
Where Campfire wins — and when to choose it
Concessions first, without caveats.
- It is a finished product and we are not. A lean finance team can close the books in Campfire this quarter. Ledgerbook is a specification and a phased build with no shipped commercial release. If you need to close next month, this comparison has one answer and it is not us.
- Subledger depth we deliberately do not build. ASC 606 across usage-based and hybrid billing, ASC 842 leases, fixed assets and prepaids, with the schedules maintained for you. That is ERP work, it is genuinely hard, and it is an explicit non-goal for a data layer (NG-2).
- Certifications in hand. SOC 1 and SOC 2 Type 1 and Type 2 are issued today. Our SOC 2 Type II is targeted inside PH-2 and we do not claim it.
- Implementation without a systems integrator. 4–8 weeks run by their own team, with historical migration included. For a 2–10 person finance team that is a decisive advantage over the integrator-led ERP norm.
- The Committed layer ships today. Reading revenue, prepaid, fixed-asset and lease schedules forward, with no AI in that layer, is a well-designed idea and it is in customers' hands. Ours is a decision on a page.
The committed-schedule argument, answered plainly
Campfire's launch post makes a structural claim worth quoting rather than paraphrasing: that their subledgers update continuously, so the Committed layer "is only possible for a system that already owns the ledger," and "no tool sitting outside the ERP can produce the Committed layer, because it doesn't have access to the schedules that generate it."
The premise is correct. A planning tool that receives a trial-balance export cannot show what is already contracted, invoiced or scheduled to amortise, so it models the whole month as an assumption — including the parts that are already known. That is a real and well-described failure of the FP&A-on-exports architecture.
The conclusion does not follow. What the capability requires is that the schedules are first-class ledger data. It does not require that one vendor also owns the application layer on top. Campfire reads that premise as "buy the ERP." The same premise reads equally as "put the schedules in an open ledger of record, where every application — their ERP, your planning tool, an agent, an auditor — can read the same forward view." Which reading is better depends on whether you run one system or several.
What we would not do is claim the capability before specifying it. Until 22 September 2026
this page carried our side of the argument as roadmap, because Ledgerbook disclosed maturity on
every read — how much of a period is final, how much provisional, how old the oldest provisional entry is,
whether the underlying accounts reconcile (FR-350) — but held no schedules of its own. That gap is
now specified: committed positions are recorded as ledger entries bound to an obligation, and
committed is a band on the same maturity object every read already returns (FR-240, FR-241,
PH-1). The boundary that does not move: we record what the owning subledger computed and relate it to its
source. We do not compute amortisation, depreciation or revenue-recognition schedules, and an ERP that does
is doing work we deliberately leave to it.
One distinction their post draws that we agree with and had not published: a forward view of committed schedules is not a continuous close. Continuous close changes when entries post. Reading existing schedules forward changes nothing about when anything posts — the accounting team still reviews and posts at close, which is what auditors expect. Ledgerbook's one-way finalization makes the same distinction: Provisional → Final is a governed status transition, not an accelerated calendar.
How Ledgerbook differs — three things, no more
The ledger is the server, not the client
Campfire's MCP surface points inward: Ember consumes your other systems and acts inside Campfire, and their post makes the case for keeping it that way. Ledgerbook points outward — the book of record is itself the MCP server, inside your deployment, air-gap included, with governance at the credential rather than in the prompt.
FR-343/220 · PH-1 read and propose
Plan and actual in one ledger, on one axis
Scenario is a native dimension, not a separate module: actual, planned, simulated and custom share the
ledger with per-scenario double-entry, computed variance that drills to the posting, and planning reads
and writes that need no export. Forecast is a preset of planned, not a product.
FR-300–345 · PH-1 full mode
Proof an auditor can check without us
Chain-hashed Final entries verifiable online or offline, typed corrections rather than edits, and an OCEL 2.1 export with an independently runnable verifier. Campfire publishes an audit trail; the difference is whether a third party can verify it without vendor access.
FR-118/119/121/905 · PH-1
Ask any AI-native ERP these seven questions
The checklist behind this page — run it against us, and against anyone else on your shortlist.
- Which way does the MCP surface point — can an outside agent read your ledger, or only your agent read outside systems? ours: the ledger is the server · PH-1
- What is the immutability proof object — can a third party verify it without vendor access? ours: online and offline chain verification · PH-1
- If we leave in three years, what comes with us — and in whose format? ours: OCEL 2.1 JSON + verifier, no proprietary formats (NG-8) · PH-1
- Where can the data legally run — SaaS region, BYOC, self-host, air-gap — and does the agent surface survive that deployment? ours: self-host and air-gap first-class · PH-1
- When an AI-proposed entry is wrong after posting, what happens — edit, delete, or typed correction? ours: typed corrections only — reversal, adjustment or restatement · PH-1
- Can a planning tool read what is already committed for next month, or only a trial balance? ours: maturity on every read, with a committed band · PH-1
- What is shipped today versus roadmap, and is every unshipped item labelled as such? ours: dated changelog · phase labels site-wide
Campfire comparison FAQ
Which should we choose — Campfire or Ledgerbook?
They are not the same purchase. Campfire is an ERP: it replaces the system your accounting team works in. Ledgerbook is a data layer under whatever systems you already run, including an ERP. If you are replacing QuickBooks or NetSuite and want one product where the team closes the books, Campfire is a serious candidate and Ledgerbook is not a substitute. If you need one auditable book of record across several source systems, deployable in your own infrastructure, that is the layer Ledgerbook occupies.
Campfire says only a system that owns the ledger can show committed amounts. Is that true?
The premise is right and the conclusion does not follow. A tool consuming a trial-balance export genuinely cannot show what is already contractually determined — that is the FP&A failure mode they describe correctly. What the capability actually requires is that the schedules are held as first-class ledger data, not that one vendor owns the application on top. They conclude you should buy the ERP; the same premise supports putting the schedules in an open ledger any application can read. Until 22 September 2026 we carried our side of this as roadmap, because we disclosed maturity on every read but held no schedules. It is now specified: committed positions are recorded as ledger entries bound to an obligation, and committed is a band on the maturity object, shipped at PH-1. We record what the subledger computed; we do not compute it.
Does Campfire have an MCP server?
Campfire shipped an MCP store in May 2026, and the direction matters. It is inbound: Ember consumes third-party MCP servers — including any hosted MCP server added by URL — and then acts inside Campfire. As of 2026-09-22 no published MCP server exposes Campfire's ledger to an external agent, and their post argues against that design on data-control grounds. Ledgerbook points the other way: the ledger is the server, and it runs inside your deployment. Both are defensible; they are opposite bets on where governance belongs.
Can Campfire and Ledgerbook be used together?
Yes, and that is the likelier shape. Campfire is a system of entry with an API, webhooks and 100-plus integrations; Ledgerbook is a downstream book of record that ingests from source systems. A group running Campfire in one entity and a different ERP elsewhere — after an acquisition, or across regions — is exactly the case a neutral layer underneath exists for.
Campfire trained its own accounting model. Does Ledgerbook do that?
No, and deliberately (NG-4). Campfire's differentiator is Accounting Intelligence, a proprietary model they report at above 95% accuracy on structured accounting tasks. Ledgerbook ships no models in the core. The bet is different: models improve and get replaced, so the durable asset is the governed surface they write through — proposal-only credentials, materiality tiers, approvals reserved to humans and policy, and a provenance event on every action. If their model is the better model, it can still propose into our ledger under those rules.
Pick the layer, then the product
Design partners get the side-by-side pack, including the axes where an AI-native ERP is the better answer.
Campfire is the trademark of its owner and is used here as an adjective for comparison only; no logos, no implied endorsement or partnership. Every competitor claim above traces to a public source fetched on 2026-09-22 and recorded in m8; funding is from dossier 14 (2026-09-19). This page is re-verified quarterly and within 14 days of a Campfire launch or changelog entry. Campfire's Forecast had no product page, no llms.txt entry and no changelog entry at the time of capture, four days after announcement — if that has changed, the cells above are stale and we want to know. If a fact is wrong, tell us and it is corrected and re-dated.