Maxima

Maxima is accounting-automation software for teams that want agent-prepared close work while retaining accountant review and approval. Its public materials describe agents that prepare journal entries, balance-sheet reconciliations, schedules, transaction matches, variance explanations, and supporting documentation; its close workspace adds owners, dependencies, review, and risk visibility. [S1][S2][S3]

The fit is a controllership team that already knows its policy, source of truth, exception process, and posting authority for a repetitive workflow. The trade-off is significant: connected financial data and repeatable logic can remove preparation work, but incomplete data, a wrong mapping, or a loose approval boundary can create a convincing but incorrect accounting output. Pilot one low-risk workflow against a historical period before expanding.

Best for: Mid-market or enterprise accounting teams with stable source data, repeatable close procedures, accountable preparers and reviewers, and time to validate one workflow at a time.

Not for: A team that cannot define the policy, data owner, source completeness, exception path, reviewer, or correction procedure; a buyer seeking unattended accounting judgment or posting; or an organization unable to obtain its required contract and security evidence.

Prepare a recurring accounting journal

• Trigger: A period close reaches a scheduled payroll, accrual, allocation, prepaids, depreciation, lease, commission, or cash-entry step.
• Inputs: Approved source reports, effective dates, account and entity mapping, policy logic, prior-period context, materiality threshold, and enabled integration permissions.
• Output: A prepared journal and supporting schedule or calculation. Maxima lists these recurring accounting tasks as agent-prepared examples. [S1][S3]
• Human checkpoint: An authorized accountant checks source completeness, cut-off, accounting treatment, mapping, calculation, evidence, exceptions, and final posting authority.
• Success measure: Preparation time, correct-entry rate, reviewer overrides, late adjustments, post-close corrections, evidence completeness, and recovery time.

Match and reconcile transactions

• Trigger: Bank, billing, invoice, ledger, or intercompany feeds are available for the reconciled period.
• Inputs: Source transactions, account mapping, matching rules, tolerance and materiality thresholds, prior balance, supporting documentation, and exception ownership.
• Output: Matched items with evidence plus an unresolved queue. Maxima documents transaction matching and balance-sheet reconciliations as product and agent examples. [S1][S3]
• Human checkpoint: A preparer investigates breaks; the account owner validates the conclusion, clears only supported differences, and approves the reconciliation.
• Success measure: Correct-match rate, unmatched-item age, false matches, reconciliation breaks, reviewer rework, and time per account.

Investigate a material variance

• Trigger: A configured threshold or monitoring rule flags a material account movement.
• Inputs: General-ledger activity, source transactions, period comparisons, entity and account dimensions, policy context, supporting documents, and investigation criteria.
• Output: A transaction-level driver view, draft explanation, and exception routed to an owner. [S2]
• Human checkpoint: The responsible accountant checks whether the variance is valid, missing context, an error, or a policy issue and documents the conclusion.
• Success measure: Useful-alert precision, missed material errors, investigation time, false-positive rate, resolution age, and post-sign-off changes.

Coordinate a controlled close task

• Trigger: A close task is due, blocked, dependent on another task, or reaches a review stage.
• Inputs: The close calendar, owner assignments, dependencies, due dates, status, evidence requirements, and escalation rules.
• Output: A visible task state with the work, owner, review, and blocker connected in one close workspace. [S2]
• Human checkpoint: The controller or assigned close owner assesses readiness, escalates a control break, and owns completion rather than treating a dashboard status as proof.
• Success measure: On-time completion, blocker age, missing-review rate, late close tasks, rework, and number of post-close adjustments.

1. The buyer defines one recurring accounting procedure: its source systems, policy, mapping, expected output, exception path, review boundary, and accountable owner.
2. Maxima connects the selected financial sources and applies configured logic to prepare the journal, schedule, match, reconciliation, or explanation. Maxima describes integration with ERP, bank, payroll, billing, and data systems, but the buyer must validate its own data and authority scope. [S1][S2]
3. The agent output carries the supporting inputs, transformation context, and a review-ready draft. [S2][S3]
4. An accountant reviews the evidence, resolves exceptions, and approves or rejects the result. Maxima says this is an enforced human sign-off boundary for GL-bound work. [S2][S4]
5. The buyer retains the source snapshot, rule version, output, review decision, posting reference, exception resolution, and manual fallback needed to reproduce or recover the close work.

The key control is not the label "agent." It is the reproducible chain from source data through accounting logic, review, final action, and correction. Treat incomplete data, changed policy, altered mapping, missing access, or an unexplained exception as a reason to stop and investigate, not as a prompt for the system to fill in the gap.

Verified facts from current vendor material: Maxima documents agent-prepared financial-close tasks, materiality thresholds, transaction-level investigation, routed exceptions, review and approval workflows, and quote-based commercial packaging. Its security page states enforced human sign-off for GL-bound work and publishes its stated control and hosting positions. [S1][S2][S4]

Vendor claims: Maxima presents its system as accurate, auditable, and fast to implement. Its Zendesk story reports customer-specific transaction matching, automation, time, and capacity outcomes. Those are vendor-published claims with context, not a forecast for another buyer. [S2][S5]

B2Bagents assessment: Maxima is best evaluated as a controlled preparation layer for repeatable accounting work, rather than a replacement for accounting judgment. It can be valuable where a team repeatedly gathers the same source data, applies stable logic, and rebuilds the same support schedules. It is a poor first use where the data, accounting policy, ownership, or recovery path is unsettled.

Unknowns: Public material reviewed does not establish the buyer's contracted connector inventory, data mappings, write permissions, implementation plan, service levels, complete pricing, audit-report scope, DPA, subprocessor terms, retention, deletion process, export format, support access, contract minimums, or transition assistance. Obtain these in writing for the intended deployment.

Good-fit conditions: documented policy, stable account and entity mapping, recurring volume, reliable source data, named preparer/reviewer/approver roles, and a narrow first workflow that can be compared with a historical baseline.

Poor-fit conditions: a one-off judgment, volatile policy or chart-of-account changes, missing master data, unclear source ownership, material entries without timely review, or an expectation that an agent removes the controller's accountability.

Likely failure modes: stale or duplicate source records produce a complete-looking but wrong entry; a mapping change sends activity to the wrong account or entity; a tolerance hides a material exception; an approval is bypassed or assigned to the wrong person; or a reviewer accepts an evidence-rich draft without applying accounting judgment.

Controls: freeze and version the workflow; test against a historical period; use segregation of duties; require source-to-output evidence and exception routing; sample outputs; alert on post-sign-off changes; test rejection, correction, reversal, and emergency disablement; and retain a manual close process for the pilot boundary.

Start with a narrow design workshop. The controller owns policy and approval; an accounting manager owns the procedure; finance systems owns connections and posting roles; a data owner confirms source completeness; and security/procurement own the evidence and contract review. Maxima documents broad system categories, but not the buyer's actual connector behavior. Confirm each data field, integration method, refresh, service account, scope, error behavior, retry, notification, export, revocation, and rollback before enabling it. [S1][S2]

The practical pilot boundary is one recurring, low-risk preparation task. Keep the old process running in parallel long enough to compare every input, calculation, output, exception, approval, and correction. The exit plan should include exports of source records, rules, journals, schedules, reconciliations, approvals, and logs; revocation of integration access; a way to complete open work manually; and a recoverable independent workpaper.

Maxima's public security page states that it handles financial-system data such as GL transactions, journals, statements, reconciliations, supporting documentation, and agent outputs as customer confidential; hosts data in US Google Cloud data centers; uses AES-256 at rest and TLS in transit; and offers SSO/MFA, immutable logs, deletion on demand, and named assurance claims. It also states that OpenAI, Anthropic, and Google are inference-only model providers under agreements that prohibit training, fine-tuning, or retention of customer data. [S4]

These are vendor statements, not a substitute for buyer diligence. Ask for current, scoped reports under NDA; the DPA; subprocessors and model terms; data-flow and retention diagrams; role configuration; support-access and incident terms; export and deletion behavior; and the exact enforcement point for approvals and segregation of duties. Verify whether any workflow can write to an ERP, how that right is limited, and how the right is removed.

Maxima does not show a public starting price. Its product page describes a platform fee based on business size plus per-module fees tailored to transaction volume, entity count, and system complexity. [S2]

Request an itemized quote for the platform, modules, entities, users, integrations, implementation, ongoing services, usage limits, support, change requests, training, term, renewal, cancellation, data export, and transition assistance. Do not infer that a proof of concept, simple workflow, or quoted module covers production integrations or ongoing operations.

1. Scope: One recurring account or journal that has stable sources, a documented policy, an identifiable reviewer, and a reversible correction path.
2. Baseline: Capture current volume, preparation and review time, close day, exception count and age, correction rate, post-close adjustment rate, and evidence completeness.
3. Test: Run the new and existing procedures in parallel across a representative historical sample, including missing, duplicate, reversal, timing, mapping, entity, currency, and source-failure cases.
4. Pass threshold: Agree in advance on accuracy, completeness, reviewer override, exception handling, evidence, approval, and recovery thresholds; include the total implementation and operating cost.
5. Stop conditions: Any unauthorized write, unresolved material difference, missing evidence, failed approval, unexplainable output, inability to reproduce an entry, untested recovery path, or result that does not beat the baseline after review cost.

Compare Maxima with Numeric, Campfire, FloQast Transform AI Agents, Rillet, and Basis in the directory. Maxima's public material emphasizes agent-prepared accounting work across connected systems, evidence, and review controls; compare each option by the system-of-record dependency, source integrations, workflow configurability, posting authority, review model, data lineage, implementation support, pricing unit, and fit for the buyer's exact close process.

1. What can Maxima read, prepare, approve, post, or change in our actual systems? Show the connector, service account, fields, write authority, approval gate, log, revocation, and emergency disablement for one workflow. [S1][S2][S4]
2. How does a reviewer reject or correct an agent-prepared result? Demonstrate the source evidence, rule version, exception, edit, approval, posting, reversal, and recovery record. [S2][S4]
3. How does a workflow behave when data is incomplete or out of threshold? Use a difficult historical example and show the exception route instead of a clean demo case. [S4]
4. What is included in our commercial package? Obtain the platform, module, entity, integration, implementation, support, usage, term, renewal, cancellation, and export terms in writing. [S2]
5. Which public security statements become contractual commitments for us? Request current reports, DPA, model/subprocessor terms, residency, retention, deletion, audit logging, support access, and incident provisions. [S4]
6. What would make us stop the pilot? Define thresholds for wrong entries, missed exceptions, failed approval, correction latency, evidence gaps, data-quality issues, and total cost before the first close.