Campfire Large Accounting Model: How L.A.M. Works

Campfire reports 95% accuracy on reconciliations and variance detection from its Large Accounting Model (L.A.M.). For controllers and finance architects, that number is the start of a real evaluation, not the end. This piece walks through what L.A.M. actually is, what 'trained on accounting data' means in practice, and where the 95% claim is defensible against general-purpose LLMs.

What is the Campfire Large Accounting Model (L.A.M.)?

The Large Accounting Model (L.A.M.) is Campfire's proprietary foundation AI model trained from scratch on accounting transaction data, designed to categorize transactions, match payments, reconcile bank accounts, and detect variances within the Campfire ERP environment. It is the AI layer underneath Ember Agents, branded externally as Accounting Intelligence.

Campfire announced L.A.M. publicly with its Series B in October 2025 (source: Campfire blog 'Introducing LAM: The First ERP-native AI Model Built for Accounting,' October 16, 2025). The platform was co-founded by John Glasgow (former Invoice2go VP) and technical co-founder Fernando San Martin (previously back-end engineering lead at Trovata, where he handled large accounting datasets for customers including Block and Etsy). CTO Paul Nichols joined later to scale the engineering organization.

How does L.A.M. differ from a general-purpose LLM?

General-purpose LLMs (Claude, GPT-4o, Gemini, Llama) are trained on text: articles, documentation, code, and conversations. They are excellent at language reasoning. They were not built to understand a chart of accounts. L.A.M. is the inverse: a foundation model trained from scratch on accounting transactions, then fine-tuned per customer on that customer's specific chart, vendor patterns, and departmental splits.

The architectural choice here matters for compliance. With a general LLM, your accounting data is sent to a third-party API for inference. With L.A.M., the model and the data both stay inside Campfire's SOC 1 and SOC 2 Type 1 and Type 2 certified environment, with no third-party processing, source: Campfire introducing accounting intelligece.

What does the 95% reconciliation accuracy claim actually mean?

Campfire's published claim, from their own announcement: 'accuracy around 95% on structured accounting tasks, compared to roughly 80% for general-purpose models' (source: Campfire blog, 'Introducing Accounting Intelligence'). A few notes for controllers parsing this:

• 'Structured accounting tasks' is the operative phrase. This means transaction categorization against an existing chart, payment-to-invoice matching, bank reconciliation, and variance detection. It does not mean novel revenue recognition decisions or judgment-heavy estimates.
• The 80% baseline for general-purpose LLMs is consistent with broader literature. Domain-specific fine-tuning typically produces 10-15 percentage point gains on narrow structured tasks. The Campfire number is consistent with what you would expect from a well-executed accounting-specific foundation model.
• It is vendor-reported, not independently benchmarked. As of the date of this review, we are not aware of a public third-party benchmark comparing L.A.M. to general models on a standardized accounting dataset. The number is internally measured by Campfire on customer data.
• Accuracy varies materially by workflow. Bank reconciliation against a clean chart of accounts performs differently than accrual identification against a complex revenue model. Expect the 95% figure to be a portfolio average across structured tasks, not a guaranteed floor on every workflow.

The honest read: the claim is plausible, consistent with what domain-specific fine-tuning produces in adjacent fields, and verifiable on your own data during implementation. The right disposition is constructive scrutiny, not dismissal.

Where does L.A.M. genuinely outperform manual accounting work?

Based on Campfire's documentation, customer reviews on G2, and what we have observed deploying the platform, L.A.M. produces meaningful efficiency gains in the following areas:

• High-volume transaction categorization. For companies processing thousands or tens of thousands of monthly transactions, L.A.M. correctly classifies against the chart of accounts at a rate that meaningfully outpaces manual coding. The model also catches duplicates and miscoded entries before they reach the GL.
• Bank reconciliation against high-cardinality vendor lists. Matching 5,000 transactions to 800 vendors with name variations, payment processors, and payment-cycle batching is exactly the pattern-matching problem the model is built for. Manual reconciliation at that scale is where accountants lose nights and weekends.
• Period-over-period variance detection. The model flags anomalies (spend patterns shifting, vendors appearing or disappearing, expense ratios drifting) faster than a human reviewing month-end PDFs. This is high-impact during close.
• Continuous monitoring between close periods. Traditional accounting is a batch process. L.A.M. enables continuous review, surfacing exceptions in days instead of weeks. The reduced surprise factor at month-end is one of the most common positive themes in customer reviews.

Where does L.A.M. still need human review?

Domain-specific does not mean autonomous. L.A.M. is positioned by Campfire as a review-and-approve workflow, not a hands-off automation. The areas where human review is required by design:

• First-time vendor classifications. The model has no prior pattern to match against. Humans set the initial classification, and L.A.M. learns from the decision going forward.
• Unusual transaction types. Restructuring entries, M&A-related accruals, impairments, and one-time tax provisions involve facts the model has not seen. Pattern-matching strength becomes a weakness on edge cases.
• Material policy decisions. ASC 606 multi-element allocation, materiality thresholds, and accounting policy interpretations require professional judgment. L.A.M. can assemble the supporting analysis. The controller and audit committee still own the call.
• Audit-defense reasoning. The model can produce audit-ready attribution. It cannot defend a position to the auditor. The auditor will want to talk to the controller, not to a chatbot.

How does L.A.M. handle audit-defensibility?

This is where the engineering work distinguishes L.A.M. from a chatbot pointed at a finance database. The audit-defense mechanics:

• Every classification, match, and flag generated by L.A.M. carries full attribution. The model documents why a transaction was categorized the way it was, with traceability to the source data (bank feed, billing record, expense report).
• Every action is logged, attributed, and reviewable in the platform. Auditors get the same provenance documentation for AI-generated entries as for human-generated entries.
• Campfire is SOC 1 and SOC 2 Type 1 and Type 2 certified. The model operates entirely within Campfire's certified environment. Customer data is not sent to external model providers for inference, which is a meaningful distinction for SOX-sensitive operations.
• 1,200+ granular permissions support role-based controls over which actions L.A.M. can take autonomously, which require explicit approval, and which are gated to specific role types.
• Campfire has stated a policy of no training on customer proprietary data, addressing the concern that customer financials could leak into a shared model layer.

For pre-IPO and post-IPO controllers, this is the headline. AI-generated journal entries now carry provenance documentation that satisfies auditor expectations. The architectural choice to keep the model inside the certified environment is what makes the workflow defensible.

What's next: agentic vs assistive AI in finance?

The trajectory across the AI-native ERP category, including L.A.M., is from assistive to agentic. Assistive AI suggests and waits. Agentic AI acts and reports.

The Ember Agents launch in March 2026 was Campfire's first step into agentic workflows. Today, agents run accruals, AP/AR processing, transaction matching, and flux analysis in the background and surface results for review. The next 12 months will likely bring deeper autonomous workflows, conditional on customer comfort with the audit-trail design and on continued model improvement.

The controller's question is not whether agentic AI is coming to accounting. It is which workflows are appropriate to run agentic today, which to run assistive, and how to graduate workflows from one mode to the other as confidence builds. The platform supports that progression by design. The implementation choice is yours.

Zanovoy is a Campfire implementation partner. We help controllers and finance architects evaluate L.A.M. against their actual workload, scope which workflows to deploy agentically vs assistively, and design the permission structure that makes the platform defensible to your auditor.

Frequently Asked Questions

What is the Campfire Large Accounting Model (L.A.M.)?

L.A.M. is Campfire's proprietary foundation AI model, trained from scratch on accounting transaction data and fine-tuned per customer on that customer's specific chart of accounts and vendor patterns. It powers transaction categorization, payment matching, bank reconciliation, and variance detection inside the Campfire ERP environment.

Is the 95% reconciliation accuracy claim verified?

It is published by Campfire, measured internally on customer data, and presented in comparison to roughly 80% for general-purpose models. As of the date of this review, we are not aware of a public third-party benchmark. The claim is consistent with what domain-specific fine-tuning typically produces on structured tasks and is verifiable on your own data during implementation.

How does L.A.M. differ from using Claude or GPT-4 for accounting?

Three differences. First, training corpus: L.A.M. was trained on accounting transactions, not on web text. Second, data location: L.A.M. and your accounting data both stay inside Campfire's SOC-certified environment, while general LLMs require sending data to an external API. Third, audit attribution: L.A.M. carries native provenance documentation for every classification, traceable to source data.

Does Campfire train L.A.M. on my company's data?

Per Campfire's stated policy, no training on customer proprietary data. L.A.M. is fine-tuned per customer (it learns your chart of accounts, vendor patterns, and departmental splits), but customer data is not used to train the shared base model. The platform is SOC 1 and SOC 2 Type 1 and Type 2 certified.

Can L.A.M. close the books autonomously?

No, and Campfire does not claim it can. L.A.M. is built for review-and-approve workflows. Agents handle high-volume structured tasks (categorization, matching, reconciliation, variance detection). Material policy decisions, novel transactions, and audit defense remain with the controller and audit committee.

How long does L.A.M. take to learn my chart of accounts?

The per-customer fine-tuning happens during platform implementation and continues as the model observes accounting team decisions. Expect meaningful accuracy on your specific chart within the first 30 to 60 days of go-live, with continued improvement as the model observes more decisions. This is one reason we recommend a shadow-mode period before activating autonomous workflows.

Evaluating L.A.M. against your workload?

If you are evaluating L.A.M. for your finance operations, the right next step is testing the model on your actual chart, vendor list, and transaction profile. Zanovoy can scope a Campfire pilot focused on your highest-volume workflows and the controls that matter to your auditor.

Schedule a free Campfire L.A.M. assessment to pressure-test the model on your actual chart, vendor list, and transaction profile before you sign.