Campfire brings accounting agents into its ERP

Campfire is an accounting ERP that combines a general ledger, revenue automation, reporting and Ember AI agents. It aims to automate recurring preparation while keeping the underlying records and actions available for review. For finance teams, the practical decision is whether its accounting model, migration process and approval settings fit their business. The agents are part of that decision, but their value depends on the quality of the books and the controls around changes.

01 / ProductEmber operates within a broader accounting system

The current product overview places core accounting, revenue, reporting and close management in one platform. Campfire’s AI features should be evaluated as part of that system rather than as a stand-alone chatbot attached to arbitrary books. The ledger and its supporting records determine what the assistant can explain and what an automated workflow is able to change.

The core accounting page describes consolidation, currency handling, reporting and granular permissions. Those are foundational ERP requirements. Before comparing AI features, a buyer needs to establish that account structures, entities and reporting dimensions can represent the organisation’s financial activity faithfully. An appealing assistant cannot compensate for an underlying accounting configuration that requires recurring workarounds.

Ember AI distinguishes always-running agents from on-demand work such as close preparation and reporting. It describes tasks including matching, accruals and variance commentary. The page also combines language about configurable automatic application with language about reviewing actions before posting. Buyers should resolve the exact approval behaviour of each enabled workflow rather than assume that one blanket rule applies everywhere.

02 / AudienceAn ERP option for teams with an identifiable constraint

Campfire is a plausible candidate where finance teams have outgrown an accounting system’s handling of entities, revenue complexity or reporting. The benefit is strongest when moving to a common platform reduces a known reconciliation or preparation burden. The organisation should be able to explain what becomes simpler after migration and which responsibilities will still require specialist review.

Compare Intuit when considering whether the current small-business accounting environment can continue to serve the company. Compare Sage when evaluating broader financial management and ERP options. The relevant difference is the operating scope needed by the team, including reporting, entity structures and integration requirements, rather than an unsupported general claim that a newer system is always better.

A business with a simple ledger and little recurring accounting complexity may gain less from an ERP migration than from improving its existing process. Conversely, a complex group should not accept a demonstration limited to one entity and a standard subscription. Bring the difficult cases into the evaluation early, so the implementation plan reflects the work that actually consumes the finance team’s time.

03 / WorkflowProposed workflow: migrate history and prepare a reviewed accrual

Begin with a limited test entity and a historical period whose trial balance has already been approved. Preserve the source chart of accounts, transaction detail and supporting documents. Include an account that changed classification and an entry requiring a known adjustment. These cases make the migration evaluation more informative than an import containing only clean, repetitive transactions.

The migration page describes loading foundational records, mapping entries, checking balances and reconciling the new ledger against the old one. Use that sequence as an acceptance framework. Require the finance reviewer to explain any difference account by account and period by period. A matched grand total is insufficient if individual balances or historical reporting dimensions are wrong.

Once the historical baseline is accepted, choose a recurring expense for which the next period’s invoice has not yet arrived. Give the agent the authorised source records and the organisation’s approved accrual policy. Ask for a proposed calculation and entry, including any reversal. Keep the exercise in a controlled environment so the reviewer can inspect the reasoning without affecting the live close.

Ember’s accrual workflow is described as maintaining supporting balances and proposed entries, with threshold-based review. In this pilot, compare the proposal with a manually prepared reference and check the period, amount and reversal treatment. Include a changed supplier contract so the agent cannot succeed merely by repeating last month’s number. The result should identify the change or leave it unresolved, rather than conceal uncertainty.

Review the actual action settings before enabling any recurring run. Determine which items can be automatically applied, which require approval and who may alter those thresholds. The product’s public wording presents both automation and human review, so the demonstration should make their relationship explicit. An audit trail is useful after a change; a clear approval boundary is needed before it happens.

Add a revenue case if that module is part of the intended deployment. The revenue automation page describes contract-based recognition, usage inputs and change tracking. Use a contract amendment and a late usage event, then inspect the effect on invoicing and recognised revenue. The finance owner should be able to trace both outputs to the applicable terms and explain their difference.

Finish by producing a management report from the test period and tracing one material movement back through the entry to the source. Then correct a deliberately wrong mapping and regenerate the report. Record the correction history and any dependent calculations that changed. The proposed pilot is complete when another accountant can understand the result without relying on the person who configured the original demonstration.

04 / PricingPricing follows accounting complexity rather than a public seat tariff

Campfire’s official pricing and implementation note, dated 9 June 2026, describes pricing based on features and accounting complexity rather than seats. It lists entities, transaction volume, revenue complexity and integration count as factors. It does not publish a numerical subscription rate, so a current proposal is required.

The dated note says platform access, implementation, support and standard integrations are included. Treat that as the published commercial description to confirm, not a substitute for a signed scope. A proposal should say which historical records will be migrated, which integrations are standard for the project and what happens if the company adds an entity or changes its revenue model.

The public implementation material also uses different timeframes: the June note describes a multi-week rollout, while the current migration page highlights rapid data transformation and a next-close ambition. These describe different portions or versions of the process and are vendor claims. Ask for a project plan separating technical import, reconciliation, configuration, training and the first accepted live close.

05 / DistinctionsMigration evidence is as valuable as migration speed

Campfire’s migration proposition includes an inspectable reconciliation between old and new balances. That is a useful emphasis because ERP transitions can otherwise leave finance teams relying on a successful import message. A good acceptance package shows the inputs, mappings, differences and final sign-off, allowing the team to revisit an issue after the implementation specialists have moved on.

The developer tools page describes integrations in which customers choose the data an application can access and can disconnect it. That supports a second evaluation path: how the accounting platform connects to the surrounding stack. Test the actual records the integration needs, the permissions it requests and the behaviour when access is revoked. A connector’s existence is not proof that it supports every direction of data flow.

Agent-generated commentary also benefits from being close to structured accounting records. The useful result is a draft that helps a finance professional explain a movement and identify supporting evidence. It should remain editable and attributable. A polished explanation that collapses separate causes into one story can create more review work than a shorter draft that clearly marks what still needs investigation.

06 / QuestionsConfirm automatic application and the source-data boundary

The most consequential uncertainty is the relationship between confidence thresholds and approval. On the Ember page, configurable automatic application appears alongside a statement about approving actions before posting. Obtain a demonstration for the exact agent and account configuration. Do not infer that every agent always waits for approval, or that every high-confidence result may post without one.

Also ask which information is used by the selected AI workflow and how it is retained, exported or removed. The public page makes security and no-training statements, but the relevant contract and data-processing scope must match the deployment. A financial record may be represented in the ledger, a supporting document and an agent output; the organisation needs to know how those artefacts remain connected over time.

07 / DecisionMake adoption conditional on a traceable accounting result