Як Campfire поєднує Claude з AI-native accounting workflows

Фінансовий close складається не з одного prompt, а з десятків повторюваних переходів: імпорт транзакцій, matching, reconciliation, flux analysis, accruals, пояснення variance, review і posting. Campfire використовує AI саме всередині цього операційного контуру, де швидкість має сенс лише разом з auditability та можливістю відтворити, звідки взялася цифра.

Найцікавіша частина кейсу у 2026 році — hybrid model architecture. Ember використовує Claude Sonnet для multi-step reasoning і conversational analysis, тоді як structured transaction intelligence Campfire розвиває окремо. Це сильніший production pattern, ніж культ одного LLM: різні stages отримують модель або deterministic engine, який відповідає їхньому failure profile.

Trigger-и: новий bank feed, незакрита reconciliation item, month-end checklist task, variance понад threshold, accrual review або запит фінансового користувача до Ember. Input включає ledger transactions, bank statements, chart of accounts, entities, vendors, accounting periods, policies, prior reconciliations і permission context.

AI stage виконує classification, candidate matching, anomaly explanation, flux analysis, draft journal logic і natural-language reporting. Для розрахунків Campfire у 2026 році описує code execution, де Ember пише і виконує Python у sandbox, щоб результат був output коду, а не арифметичною імпровізацією LLM. Output — evidence-backed candidate, explanation або draft action із source references і status, а не мовчазна зміна ledger.

• Trigger → transaction, close task, exception або analyst query.
• Input → authoritative finance data + policy + entity/period context.
• AI → reason, reconcile, calculate, explain, propose.
• Output → reviewable candidate + evidence + deterministic validation state.

A3 означає, що agent може самостійно пройти кілька read/analyze stages і підготувати bounded action, але не отримує універсального права постити journal entries, змінювати accounting policy або закривати period. Low-risk auto-approval можливий лише для заздалегідь визначених transaction classes з materiality threshold, stable historical quality і reversible postcondition.

Перед write application повторно перевіряє actor, tenant, entity, period status, account, amount, currency, duplicate key і approval policy. Якщо запропонована дія змінилася після review, approval invalid. Усі consequential changes мають ledger-side operation ID і read-after-write verification.

Failure modes: duplicate bank transaction, stale feed, wrong entity, currency mismatch, model invents account mapping, calculation rounding error, period already closed, write timed out after фактичного posting або retried event створив duplicate. Кожен із них потребує machine-checkable terminal state, а не лише текстового повідомлення користувачу.

Правило після unknown write — reconcile first, retry second. За idempotency key і external operation ID система читає authoritative ledger, визначає, чи дія вже відбулась, і лише потім повторює або ескалює. Для math-критичних outputs застосовуються deterministic formulas або code execution з fixtures, expected totals і tolerances.

Eval corpus повинен мати normal transactions, ambiguous vendors, multi-currency, intercompany, duplicates, stale periods, missing documents, adversarial descriptions, prompt injection у invoice memo та cases, де правильна відповідь — abstain. Graders окремо оцінюють evidence selection, classification, calculation, policy compliance, explanation і final ledger state.

Average score не перекриває material error. Unauthorized posting, wrong entity, duplicate journal, unsupported accounting assertion або cross-tenant exposure — hard blocker. Після production incident мінімальний reproducible case переходить у permanent regression suite разом із model/prompt/data fingerprint.

Transaction matching і exceptions можуть працювати continuously, close analysis — за event/period schedule, conversational Ember — on demand. Масштабування краще будувати через queue by entity/period, щоб сотні parallel tasks не боролися за один ledger lock і не створювали race під час close.

Full cost = model tokens + retrieval/data queries + code sandbox + reconciliation compute + integration fees + audit storage + human review + failed/replayed runs + evals + platform support. Кращий denominator — cost per verified reconciled item або accepted close task, а не token cost одного chat turn.

Мінімальний control plane: row/entity permissions до model context, immutable source references, no-secret logging, approved tool allowlist, schema validation, materiality rules, segregation of duties, approval expiry, audit ledger і kill switch для write capabilities. Prompt чи retrieved memo не може розширювати роль користувача.

Головний прихований ризик — змішати current Campfire product claims. Historical Anthropic case про Claude і current Campfire Accounting Intelligence стосуються різних model layers. При відтворенні треба versionувати model registry й не переносити metric одного шару на інший лише тому, що в UI обидва називаються AI.

1) Виберіть read-heavy flux analysis або reconciliation candidate generation. 2) Зафіксуйте authoritative finance schema та permissions. 3) Додайте evidence links і deterministic math checks. 4) Проженіть historical close periods offline. 5) Запустіть shadow поруч із поточним процесом. 6) Дозвольте bounded reversible actions з exact approvals та idempotency. 7) Розширюйте autonomy лише після stable regression history і rollback drill.

Підходить finance teams із чистими source systems, визначеними accounting policies та audit ownership. Не підходить середовищу, де ledger сам не є надійним source of truth, approval matrix живе в Slack, а month-end exception закривається аргументом 'ми так робили минулого разу'.