Auxiliar AI is a workflow application for the accounting cycle. Its architecture connects the source accounting system to structured data, specialist workers and an accountant’s review workspace. The central design decision is to preserve the meaning of a transaction as it moves from a document, through a proposed treatment, into posted accounting and financial reports. Invoice and bank workflows are in use; the month-end close and client-knowledge components described here are being added.
The platform runs invoice and bank workflows; its design connects them to month-end close and client-knowledge controls, from source documents to final accounting.
01 / The problem
One accounting cycle, several kinds of reasoning.
The same bank payment can relate to an invoice, a payroll obligation, a tax liability or a transfer between accounts. The amount alone does not identify the treatment. A worker needs the source event, the client’s chart of accounts, relevant history and the state of work already completed.
The monthly workflow also has dependencies. Invoice and other-entry work inform bank reconciliation; reconciliation informs close preparation; the final audit considers the assembled month. Each handoff must preserve client, period and run identity so a later stage can distinguish completed work from an incomplete or unrelated run.
02 / Inside the system
From the existing accounting system to a reviewable workspace.
Onboarding starts with accounting backups and their associated files. Run-specific cloud storage preserves the inputs. SQL Server restores the backup; BigQuery supplies structured accounting facts; Firestore holds workspace and report projections. Python APIs expose the services to the Next.js and TypeScript interface.
During the month, invoice XML, bank evidence and supporting schedules enter the domain workflows. Parsing and supported arithmetic produce inspectable facts. Workers propose treatments against those facts and the chart of accounts. The workspace gives an accountant access to the entries, explanations and exceptions before final accounting changes.
- Application
- Next.js / React / TypeScript workspace; Python APIs and domain services.
- Source and data
- Accounting backups, invoice XML, bank documents and support schedules; cloud storage, SQL Server, BigQuery and Firestore.
- Agent runtime
- OpenAI Responses, role-specific prompts and tools, structured results, task/run identity and domain audit.
- Accounting lifecycle
- Proposed entries, professional review, authorized posting, report validation and period close.
03 / Inside the system
A coordinator, specialists and a separate audit.
A domain coordinator defines the work and dispatches scoped tasks to specialist workers. Invoice families cover supplier accruals, customer invoicing, payroll and credit notes. Bank reconciliation has workers for settlements, fees, payments, transfers and residual exceptions. Close preparation groups work into assets, payroll, taxes, verification and bank alignment.
The runtime resolves prompts, model configuration and permitted tools for a role. Workers can request scoped account information, document facts and historical summaries, and return structured results. A separate domain auditor assesses the assembled proposals. Invalid output or missing support remains visible for review.
Bank orchestration adds an ownership ledger for claimed transactions, staged execution and checkpoint verification. These mechanisms matter when several workers could interpret the same movement: a resumed run needs to know what has already been claimed and which saved state it can trust.
A worked example
Follow one depreciation entry through the close design.
Example with invented data.
01 / Supported inputAn approved monthly schedule
A period-start fixed-assets registry identifies the assets in scope. An accountant-approved monthly schedule supplies a depreciation amount of MXN 2,400 and existing mappings for depreciation expense and accumulated depreciation. The worker receives the client, period and source identity with that support.
02 / Bounded preparationA worker prepares the draft
The assets task validates the required support and account mappings. Supported code prepares the debit and credit lines; the worker returns the proposal with its explanation and source references.
03 / Structural checkBalance is necessary
Debit depreciation expense: 2,400. Credit accumulated depreciation: 2,400. Debits equal credits, so the entry is structurally balanced. Whether the schedule and accounts are appropriate is the reviewer’s question.
- Depreciation expense
- Debit 2,400
- Accumulated depreciation
- Credit 2,400
04 / Accounting reviewInspect the treatment and the support
Audit and accountant review consider the source schedule, selected accounts, period and completeness. If the schedule or mappings are missing, the task exposes the gap for review instead of inventing an entry.
05 / Authorized resultPosting has its own authority
Approval authorizes the proposed treatment; posting makes the entry canonical and report affecting. Final period completion checks the assembled accounting and reporting state before the period can be closed.
04 / Inside the system
Client knowledge needs an identity and a time boundary.
Accepted accounting treatments can become reusable knowledge, but the next month must be able to identify exactly which knowledge it received. The publication path binds approved content to a client, period, immutable version and integrity checks. A verified publication and a matching selector identify the approved version eligible for that client and period.
The execution path selects the latest approved, published knowledge through the preceding month; current-month source data is supplied separately. A worker preparing a month should not obtain the answers to that same month from its historical context. Publishing a corrected version also needs recoverable state: immutable cloud objects and the database selector are coordinated without pretending that two different storage systems share one transaction.
05 / Inside the system
Three choices that shape the implementation.
These choices place accounting meaning, execution authority and test independence into separate parts of the system. Each introduces engineering work as well as a useful control.
- Decision 01
Keep source facts and supported calculations deterministic.
Parse document fields and calculate supported amounts in code; let AI interpret accounting relationships within a scoped task.
An accountant can inspect the facts and calculation separately from the proposed treatment.
Trade-off. Domain rules, parsers and support validation require dedicated engineering; a correct amount still needs the correct accounting treatment.
- Decision 02
Give each worker a bounded role and eligible context.
Separate specialist tasks, approved client knowledge and tool permissions; preserve client, period and run identity through handoffs.
The system can explain what a worker was allowed to see and which sources informed its output.
Trade-off. Version selection, ownership and recovery must be coordinated across the workflow.
- Decision 03
Separate the proposal from its evaluator and final authority.
Audit assembled work independently and preserve accountant approval, posting and period close as separate lifecycle actions.
A model’s persuasive explanation cannot by itself grant authority to change the ledger.
Trade-off. Review and exception handling become first-class product workflows, with their own operating responsibilities.
06 / Inside the system
Test the accounting, the boundaries and the recovery paths.
A balanced journal is only the first check. Evaluation also asks whether the treatment uses the right accounts, follows the source evidence, covers the relevant transactions and produces coherent account balances and reports. Missing schedules, unresolved mappings and incomplete bank work must be visible in the result.
The evaluation freezes the worker’s output before a separate evaluator obtains the approved reference accounting. Reference answers stay outside the worker’s tool context, so the comparison is between generated work and independently approved accounting.
Contract tests examine malformed results, missing approvals, period eligibility, restricted tools, continuation state and publication failures. Workflow testing then follows the assembled month through review and reporting. Professional acceptance of each release is a separate decision from these checks.
- Did the worker use eligible information?
- Inspect the client, period, selected knowledge version, permitted tools and source references.
- Is the accounting complete and coherent?
- Compare entries, coverage, account balances and reports with the approved reference after freezing the output.
- Can the workflow recover safely?
- Exercise duplicate ownership, failed tasks, saved checkpoints and publication failures; verify state before resuming.
07 / Inside the system
Deliver the workflow across accounting and engineering.
The project starts with an existing operational process and its accounting sources. Product and accounting work define the tasks, exceptions and decision rights. Engineering connects the data pipeline, domain services and review interface, then exercises the dependent stages as a complete month.
The team introduces new capabilities through integration checks, accounting comparisons and professional acceptance of the specific release. The work connects requirements and implementation to an operational decision: which tasks are ready for use, which exceptions remain and who owns the resulting accounting.
The people around the workflow.
- Accounting professionals
- Define treatments, resolve exceptions, review proposed entries and authorize accounting.
- Product and engineering
- Translate accounting requirements into data contracts, bounded worker tasks, review interfaces and release checks.
- Firm operations
- Provide the client context, source material and feedback needed to introduce the workflow into daily practice.
Technology and integrations
Services in the workflow.
- OpenAI APIAI service integration
Responses API for scoped specialist tasks and structured outputs.
2025–2026 · Specialist workflow
- Google CloudData infrastructure
Cloud Storage run inputs, BigQuery accounting facts and Firestore workspace/report projections.
2025–2026 · Data architecture
Cloud Storage
BigQuery
The design principle
Keep the source facts, the proposed treatment and the accounting decision separate, and connect them at every handoff.