• Series voir-pages
  • page 09 / 26
  • department 4 of 8
  • implemented 0 functions

AI finance is not “count what we spent”. It is a ledger book, a forecast and a cash gap you see in advance.

In VOIR AI the finance department treats money as data: every operation is an entry with a source, every category has a limit, every period is a line in the payment calendar. The department calculates, compares and warns — it does not move money. Payments, write-offs and limit changes stay with a human. Below is an interactive demonstration on invented figures: four panels, a scenario switch and the tables the charts are built from. Next to it — the honest picture: what the department should do according to the target architecture, what already works inside our own tooling, and how the department is wired into the AI CEO cycle.

VOIR AI product · zero functions implemented Marisova ecosystem · cost tracking per task and generation budgets Demonstration · figures invented

Open the demo dashboard Honest statuses

Demonstration · finance department panels

Four panels: ledger, forecast, control, billing

The dashboard is built to reveal the structure of the finance loop rather than to show pretty numbers. The first panel consolidates receipts and spend by business line. The second lays the balance across the payment calendar and shows in which period it drops below the minimum-balance limit. The third compares actual spend against the limit by category. The fourth breaks invoices down by due date. The scenario switch affects only the second panel: the same business produces different cash gaps depending on when payments land. Every panel is duplicated by a table of numbers — the chart is built from the table, not the other way round.

Structural numbers on this page: 5 department functions, 4 dashboard panels, 8 departments in the architecture, 0 functions implemented in the product.

Finance dashboard · ledger → forecast → control → billing

Demonstration · invented figures

Ledger: receipts and spend by business line

Each row is a business line, each bar is a total for the demo period. Net is the difference, and it shows which line carries money and which one eats it. A line with a negative net is neither a verdict nor a reason to shut everything down: it is a question for whoever set the price and the plan. The finance role records the discrepancy and passes it on together with the data source; the decision belongs to the owner.

  • Receipts — total across all lines
  • Spend — total across all lines
  • Net — receipts minus spend
Static ledger diagram: five business lines, receipts and spend. The exact figures are in the table below. 03106209301 240SubscriptionsProjectsTrainingPartnersOther RECEIPTS / SPEND · ARBITRARY UNITS, DEMO
  • receipts
  • spend
Demo ledger data by business line. The figures are invented to illustrate the layout; currency is deliberately unnamed — these are arbitrary units.
Business line Receipts Spend Net

Forecast: balance across the payment calendar

The forecast is built from two lists: what is due to come in and what is due to go out in each period. The line shows the closing balance, the dashed mark is the minimum-balance limit, and the red zone below it is a cash gap. The point of the panel is that the gap is visible in advance: not “we ran out of money”, but “in period three we will be short by this much”. The scenario switch changes the dates and volumes of receipts, and with identical spend the gap appears or disappears.

  • Opening balance — before the calendar starts
  • Closing balance — end of period eight
  • Minimum — below the limit means a gap
  • Periods with a gap — balance below the limit

Static forecast diagram: the balance line across eight periods (baseline scenario), the minimum-balance limit as a dashed line, and the cash-gap zone below it. Exact figures are in the table below. 7859631 1421 3201 499 MINIMUM BALANCE LIMIT 900 Period 1Period 2Period 3Period 4Period 5Period 6Period 7Period 8 CASH GAPS: 0 · SCENARIO “BASELINE”
  • closing balance
  • zone below the limit · cash gap
  • minimum balance limit
Demo payment calendar, scenario “Baseline”. Invented figures, not a client’s data.
Period Receipts Outflows Balance Gap

Control: actual spend against the limit

A limit is an agreement, not a wish. That is why this panel shows not “how much was spent” but “how much was spent relative to what was agreed”. The dashed mark is the limit boundary; a bar that reaches past it is an overspend. An overspend does not automatically block work: it goes into the report with a reason, when the reason is visible in the data, and it goes to the owner as a decision. The limit is not recalculated after the fact — otherwise control would vanish exactly when it is needed.

  • Total limits — across all categories
  • Actual spend — for the demo period
  • Variance — actual minus total limits
  • Categories over limit — out of six categories
Static spend-control diagram: actual spend in six categories against the limit. The dashed mark is the limit boundary; a red bar is an overspend. Exact figures are in the table below. 0239477716954Infrastructure and servicesMarketingPayrollContractorsTaxes and dutiesOther ACTUAL · LIMIT → ARBITRARY UNITS, DEMO
  • actual within the limit
  • actual above the limit
  • limit boundary
Demo limits and actual spend by category. Variance is measured against a limit that a human set.
Category Limit Actual Variance Status

Billing: invoices by due date

An invoice that has been issued but not paid is not “the manager forgot” — it is a row with a date. This panel breaks the register into ageing buckets: not due yet, paid on time, overdue up to two weeks, up to a month, and beyond. Overdue amounts are shown both as a sum and as a count of invoices, because two large invoices and twenty small ones call for different actions. Each bucket then goes to its own scenario: a reminder, a reconciliation, an escalation to the owner.

  • Invoices in the register — for the demo period
  • Billed — total across all invoices
  • Overdue — amount past its due date
  • Invoices overdue — out of the total count
Static billing diagram: five ageing buckets of invoices with amounts and counts. The exact figures are in the table below. 06511 3021 9532 604Not due yetPaid on timeOverdue 1–14 daysOverdue 15–30 daysOverdue 30+ days AMOUNT · INVOICE COUNT → ARBITRARY UNITS, DEMO
  • not due yet
  • paid on time
  • overdue
  • overdue 30+ days
Demo invoice register by ageing bucket. Share is calculated against the total of all buckets, including unpaid ones.
Invoice status Invoices Amount Share

The demonstration is not connected to a live AI service, to a bank, to an accounting system or to a payment provider: the numbers are set in the page code and were invented by us to show how the panels are built. Currency is deliberately unnamed — these are arbitrary units. None of these figures is client data, a forecast for a specific company or a deployment result: the project has no clients. Switching panels and scenarios is the only interactive action on this page; there are no forms, no request widgets and no “connect your bank” button precisely because there would be nothing for them to work with.

Ledger

An entry without a source is an opinion, not data

Accounting starts with an entry, not with a report. An entry records what happened to the money: amount, business line, category, date, and a mandatory statement of where the figure came from. If the source is not named, the number cannot be re-checked, which means every report built on it rests on trust. Below are the six kinds of record that make up the department’s financial book in the target architecture. The order is the same for any operation, whether it is a receipt from a client or an internal transfer.

POST

Operation entry

The base record: amount, sign (inflow or outflow), business line, category, date, source. One operation — one entry; merging several operations into a single line is prohibited, because after the merge it is impossible to tell which of them caused a variance.

artefacta record in the operation book stating the source of the figure

MAP

Chart mapping

The same operation is named differently in the bank, in statutory accounting and in management reporting. The mapping fixes which external account falls into which internal category, and who set that rule. Without a mapping every report is assembled from scratch and comes out slightly different each time.

artefacta map of external accounts to internal categories, with the author of each rule

RULE

Classification rule

Some entries can be classified by a written rule: payment purpose, counterparty, amount. The rule is declared before it is applied and keeps a list of exceptions. When a rule does not fire, the operation is not guessed at — it goes into a queue for a human to resolve, and that fact is visible in the report.

artefacta log of rule applications: how many operations were classified, how many went to manual review

RECON

Reconciliation

The internal book is reconciled against an external source: a bank statement, a payment-provider register, an acceptance certificate. A discrepancy is not a “technical difference” — it is a line in the report with an amount and a date. A reconciliation that always balances is suspicious: most often it means the book was compared against itself.

artefacta reconciliation record: totals on both sides, the list of discrepancies, the status of each

PER

Period close

A period closes only after reconciliation and after every unclassified operation has been resolved. A closed period is marked immutable: a change in it requires an explicit record of who changed what and why. Otherwise last month’s report stops matching itself and comparing periods becomes impossible.

artefacta period-close mark plus a log of late adjustments

GAP

The “no data” mark

Where there is no data, the book carries an explicit mark — not a zero and not a plausible estimate. Zero and “no data” are different claims: zero means “we checked, there were no operations”, while missing data means “there is nothing to check against”. Conflating the two is the most common way to produce a confident and wrong report.

artefacta list of positions with no data, each with a reason and the date the data is missing for

The book of entries is the input for every other panel: the forecast takes actual receipts and outflows from it, spend control takes actuals by category, billing takes the invoice register. That is why accounting cannot be “tidied up later”: without it the remaining functions calculate over empty data and confidently show what is not there. How the department receives work and who sets the criteria is described in the AI CEO cycle section.

Target architecture

The contract of a function: input, work, output, artefact

A function is not “the department deals with money” but a contract: what comes in, what is done, what comes out and which artefact remains. If a function has no artefact it cannot be checked independently, which means it cannot be improved either. All five functions on this page share one status: none of them is implemented in the VOIR AI product.

LGR 01 / 05
Target architecture

Ledger

  • inputoperations from external sources: statements, payment registers, certificates, internal transfers
  • outputa book of entries with sources, closed periods, a list of positions with no data

The first function is responsible not for reporting but for there being only one truth. As long as the same amount lives in three spreadsheets, the argument can go on forever and everyone will be right. The ledger consolidates operations into one book and demands that every figure names its source — otherwise the figure remains an opinion.

artefactthe book of entries: amount, business line, category, date, source, period-close mark

FRC 02 / 05
Target architecture

Forecast

  • inputactuals from the ledger, the payment calendar, the declared minimum-balance limit
  • outputbalance by period, the list of periods below the limit, scenarios for shifted dates

A forecast differs from a plan in that it answers “when does the money run out” rather than “how much do we want to earn”. It is built on dates, not amounts: identical receipts and identical spend give a different result if the dates do not line up. That is precisely why a cash gap is a calendar problem, not a business problem.

artefacta payment calendar with the balance by period and an explicit list of periods below the limit

CTL 03 / 05
Target architecture

Spend control

  • inputlimits per category, set by a human; actual spend from the ledger
  • outputvariance of actual against limit, with a reason when it is visible in the data, and the owner’s decision

Control does not block work and does not “optimise” the budget on its own. It shows a discrepancy where one exists and states it as an amount, not as an estimate. The key constraint: a limit is never recalculated to match the actual after the fact, otherwise the overspend disappears from the report at exactly the moment it needs to be seen.

artefacta variance register: category, limit, actual, difference, reason, who decided

BIL 04 / 05
Target architecture

Billing

  • inputcontractual obligations, fact of delivery, the register of issued invoices
  • outputageing buckets, reminder scenarios, escalation on large invoices

Billing ties money to obligations: an invoice appears not “when someone remembered” but when a condition from the contract is met. Overdue is measured in days and in amount at the same time, because one large invoice and twenty small ones call for different actions. A reminder is a routine operation, not a confrontation: it is sent by a written rule and recorded in the register.

artefactan invoice register with due dates, ageing buckets, a log of reminders and escalations

MGR 05 / 05
Target architecture

Management reporting

  • inputthe ledger, the forecast, the variance register, the ageing buckets
  • outputa report to the owner with explicit “no data” marks and the list of decisions left to a human

Reporting folds the four previous functions into one picture from which a decision can be made. Its contents are declared in advance, and some of the lines are about what did not work out: unclassified operations, unresolved discrepancies, positions with no data. A report in which everything always balances usually means the book was reconciled against itself.

artefacta period report: receipts, spend, net, balance, variances, overdue, open questions

Spend control

Every rule has a threshold, a reaction and an owner

Control that switches on “when somebody noticed” is not control, it is a reaction after the fact. That is why each rule declares four things: what is measured, at what value it fires, what happens next and who decides. Rules are set before the period starts, not after it ends: otherwise the threshold can always be chosen so that the actual figure turns out to be normal.

every operation

Is there a source

An entry without a named source does not reach the report: it is marked unconfirmed. What is checked is the presence of a reference to a statement, register or certificate — not whether the amount looks plausible.

threshold: source not named · reaction: operation queued for review, marked in the report

every period

Is the limit exceeded

Actual spend per category is compared against the limit a human set. The variance is calculated as an amount and as a percentage, and an overspend goes into the register with a reason, when the reason is visible in the data.

threshold: actual above limit · reaction: a line in the variance register and the owner’s decision

every forecast

Does the balance fall below the limit

The projected balance is checked against the minimum-balance limit for every period of the calendar. Future periods are checked, not just the current one: a gap noticed on the day it happens is no longer a gap, it is a fact.

threshold: balance below the limit in any period · reaction: a warning with the period number and the shortfall

every day

Is the overdue growing

The invoice register is broken into ageing buckets: an invoice that moves into an older bucket is flagged explicitly. Both the amount and the count are tracked, because a large invoice and a scatter of small ones lead to different actions.

threshold: an invoice moves to an older bucket · reaction: reminder by rule, large invoice escalated

every reconciliation

Is the data balancing against itself

A check of the check itself: a reconciliation must compare the book against an external source, not against a copy of itself. Separately, the presence of a negative control is verified — a deliberately mismatched set on which the reconciliation must report a discrepancy.

threshold: reconciliation without an external source or without a negative control · reaction: “not verified” mark in the report

every close

Was a closed period changed

A closed period is immutable: a change in it requires a record of who changed what and why. What is checked is that such a record exists, not its content — the content is assessed by independent acceptance.

threshold: an adjustment in a closed period without a record · reaction: the period reopens and the case is escalated

Thresholds and reactions are parameters of the target architecture, not statistics: they set the rhythm of control in which a deviation is found by a rule rather than by a complaint. The project has no real data on which thresholds work better, because the product has not launched; we are not going to invent an “average overspend rate”. How the executors that carry these rules are built is on the AI agents page; how the department connects to process execution is on the AI operations page.

Billing

From obligation to payment: five steps

Billing is not “issue an invoice” but a chain with a verifiable end. An invoice arises from an obligation, passes a check of its basis, goes to the counterparty, waits for payment until its due date and closes on the fact of receipt. Each step leaves an artefact, so at any moment it is visible where exactly the invoice stopped and why.

Obligation

From a contract or a confirmed volume of work arises the basis for an invoice: what, to whom, for how much and by what date. The basis is recorded before the invoice is issued — otherwise the amount is taken “from memory”.

artefact: an obligation record with source and date

Checking the basis

It is verified that the obligation is real: the volume is confirmed, the period is not closed, the amount matches the terms. The check is performed by a role that did not build the invoice — otherwise control turns into trust.

artefact: a check mark with the list of terms verified

Issuing

The invoice is created and sent to the counterparty, with a record of the date and channel. The send date is the starting point of the payment term, so it is recorded as a fact, not reconstructed afterwards.

artefact: the invoice in the register with send date and due date

Waiting and reminding

While the due date has not arrived, the invoice sits in the “not overdue” bucket. Once it arrives, the invoice moves to the next bucket and a reminder goes out by a written rule. The rule is declared in advance: text, channel, delay, number of repeats.

artefact: a reminder log — date, channel, outcome

Closing or escalating

An invoice closes on the fact of receipt, which is matched against amount and date. If payment never arrives, the invoice does not “hang around”: it is escalated to the owner together with the reminder history. Writing off a debt is a human decision, not an automatic action.

artefact: a close mark with the receipt entry, or an escalation record

None of these steps sends a payment or debits money: billing keeps the register and the dates, while the movement of money stays with a human. How independent acceptance — through which the artefacts pass — is arranged is on the AI CEO cycle page; how the sales department hands obligations into the finance loop is on the AI sales page.

Reporting

The report: what is in it and what is left out on purpose

A financial report exists not to show the movement of money. Its job is to let the owner make a decision: where to cut, which payment to move, which invoice needs a personal conversation. That is why the composition of the report is declared in advance, and a significant part of its lines is about what did not balance.

What the report contains

  • Receipts and spend by business line with the net of each — linked to the book of entries
  • Opening and closing balance for the period, the minimum inside it and the date it was reached
  • The list of periods in which the projected balance falls below the limit, with the shortfall amount
  • Variances of actual against limit by category: amount, percentage, reason when it is visible in the data
  • Ageing buckets of invoices and the overdue total, including moves between buckets during the period
  • Reconciliation results: what was compared, which discrepancies were found, which remain open
  • Positions marked “no data”, with the reason — what exactly prevented obtaining them
  • Decisions that remained with a human: payments, write-offs, limit changes

What is left out on purpose

  • Invented savings percentages and “efficiency gains” — there is nothing to measure yet
  • Estimates in place of facts: “roughly this much” does not enter the report as a number
  • Rounding that hides a variance: a difference of one unit is shown as a difference
  • Green statuses without proof — every reconciliation names its external source
  • Forecasts built on assumptions that are not declared in the report itself
  • Someone else’s credit: if the owner made the decision, the report names the owner, not the system
  • Averages where distribution matters: an average spend hides an overspend

A period report is not the department’s output but the input for the next cycle: the variances found and the discrepancies left open become tasks that the AI CEO sets. How the department gathers data for management reporting from the other loops is on the AI Operating System page; the roles that carry the department’s functions are listed in the AI CEO cycle section below.

Statuses

Two status columns: the blueprint and our own workshop

Finance is the area where it is easiest to pass a blueprint off as a working instrument: the numbers on a dashboard look convincing on their own. That is why the table is split into two columns. The left one is what is implemented in the VOIR AI product (right now, not a single function of the loop). The right one is what already works inside the Marisova ecosystem as our own tooling. The right column must not be read as a promise to a client: our internal work is not sold and is not handed over.

Status of the finance department functions as of 2 November 2026. Verified against code, configuration and live URLs — not against plans.
Function In the VOIR AI product In the Marisova ecosystem (internal)
Operation ledger (LGR) not implemented
Target architecture: a book of entries with the source of every figure		 works
Cost tracking per task exists as our internal journals: for each task it is visible what was done and how many resources it took. Not provided to clients as a service
Payment-calendar forecast (FRC) not implemented
Target architecture: balance by period, a limit, a cash-gap warning		 works
Budget control for content generation exists as an internal spend limit: the threshold is declared and the flow stops when it is reached. Our tool, not a product
Limit control (CTL) not implemented
Target architecture: actual-versus-limit variance with a reason and a decision		 works
The practice exists in fact: external API spend is capped by a quota, and an overrun is recorded in a log rather than smoothed over. An internal rule, not a product function
Billing and invoice register (BIL) not implemented
Target architecture: invoices, due dates, ageing buckets, reminders		 none
We issue no invoices to clients: the product has not launched and there are no contracts. We are not going to invent a register that does not exist
Management reporting (MGR) not implemented
Target architecture: a period report with “no data” marks		 works
Task reports are written to a single results directory, including blockers and honest reasons for non-completion. Our working loop, not a client service
Client-facing finance dashboard not implemented
Target architecture: the state of the money in one place		 demo
The panels on this page exist as a demonstration on invented numbers. This is not a product interface and not real business data
Bank and accounting integration not implemented
Target architecture: connecting external sources of operations		 none
There are no integrations with banks, accounting systems or payment providers, neither in the product nor internally. We make no “coming soon” promises
Making payments not implemented
By architecture — forbidden: moving money stays with a human		 none
The rule holds in fact: irreversible actions and operations on live systems require the owner’s confirmation

Every works mark in the right column means our own tool, which we use in our own projects — not a function of the VOIR AI product and not a promise to a client. Figures about “budget savings”, “faster period close” or SLA are absent from the table on purpose: the product has not launched, there are no clients, and the internal statistics of our runs are not a product metric. The actual status of the project is published on the About the platform page; the structure of the platform is on the AI Operating System page.

Connection to the AI CEO

The finance department does not assign itself work

In VOIR AI, finance is the executive part of the AI CEO cycle. The AI CEO accepts the task: close a period, check the forecast, find the reason for a variance, prepare data for a decision. It also distributes the work between the department’s roles and folds the result into a report for the owner. The department’s artefacts go through independent acceptance by a role that did not do the work. The table below is what the finance department does at each of the five steps of the cycle.

  1. 01 Setting the task The department receives a brief and readiness criteria fixed before the start: which period we close, which sources count as reliable, which limit is declared, what counts as the result. Finance does not assign itself work — otherwise the department starts “optimising” a budget nobody asked it to revise.
  2. 02 Analysis and allocation The AI CEO decides which part of the work goes to finance and distributes it between the department’s roles: consolidating operations to one role, the payment calendar and forecast to another, limits and variances to a third. The autonomy grade is fixed: what a role calculates itself, and what necessarily goes to the owner for confirmation — any payment and any limit change.
  3. 03 Execution The roles carry the task through the functions: entries, reconciliation, forecast, variance register, billing. Each role leaves a trail of actions and passes the artefact on together with the sources of its figures, or with an explicit “no data” mark. Where data is missing, the step is escalated instead of being padded with a plausible estimate.
  4. 04 Independent check A QA role that did not run this cycle checks the artefacts against the criteria of step 1: does the net recalculate from the book of entries, do the numbers in the chart match the table, does the reconciliation have an external source, are the “no data” positions honestly reflected. A false-green gate is checked separately: a reconciliation that always balances verifies nothing.
  5. 05 Acceptance and report The AI CEO folds the verified artefacts into one report for the owner: what balanced, which discrepancies remain open, where the forecast goes below the limit, which decisions stayed with a human. Rejected artefacts and unresolved discrepancies enter the report as they are, without smoothing.

Department roles in the target architecture

ACC

Ledger analyst

Carries the LGR function: consolidates operations into the book of entries, demands the source of every figure, closes the period and keeps the list of positions with no data. Does not substitute an estimate for a missing number.

PLN

Forecaster

Carries the FRC function: assembles the payment calendar, lays the balance across periods, declares in which period it falls below the limit. Shows scenarios for shifted dates rather than a single “average” variant.

CTL

Spend controller

Carries the CTL and BIL functions: compares actual against limit, keeps the variance register and the ageing buckets of invoices. Does not change a limit to match the actual and does not send a payment — both actions stay with a human.

Artefacts the department leaves behind

  • Book of entriesamount, business line, category, date, source, period-close mark
  • Chart mappingexternal accounts and internal categories, the author of each rule
  • Reconciliation recordtotals on both sides, the list of discrepancies, the status of each
  • Payment calendarreceipts and outflows by period, balance, periods below the limit
  • Variance registercategory, limit, actual, difference, reason, who decided
  • Invoice registerdue dates, ageing buckets, a log of reminders and escalations
  • Period reportnet, balance, variances, overdue, open questions, positions with no data

Points of contact with neighbouring departments

  • AI CEO → finance The task arrives with readiness criteria and declared limits. Without a limit, spend control has nothing to lean on: there is nothing to compare the actual against, and “normal” turns out to be floating.
  • Sales → finance The sales department passes deal obligations: amount, terms and due date. The invoice register is assembled from them — without that, billing starts with guesswork.
  • Marketing → finance Marketing hands over actual campaign spend together with the channel. Finance in return requires the source of the figure, not a “rough budget estimate”.
  • Finance → operations A period in which the forecast falls below the limit goes to operations as a constraint on the plan: dates and resource spend in that period are revised rather than executed on the old schedule.
  • Finance → development Connecting external sources of operations is a task for the development department. Finance formulates the interface requirement: source, date, amount, idempotence of a repeated load.
  • Finance → owner and QA All artefacts go to independent acceptance, and any payment, write-off or limit change goes to escalation to the owner. A role does not declare a period closed by itself.

How a single executor is built is on the AI agents page; how the headquarters assembles several departments for one task is on the AI teams page; roles across all departments are on the AI employees page.

Boundaries

What the finance department never does

Finance is the area where a mistake is measured in money and the temptation to “make it look good” is at its highest. That is why the constraints are built into the contract of the functions rather than into settings: no role of the department can bypass them, including the role responsible for finance.

Does not move money

A payment, a transfer, a write-off and a refund — only after the owner’s confirmation. The department calculates, compares and warns; by architecture, not by temporary restriction, it has no access to the banking system.

Does not change a limit to match the actual

A limit is set by a human before the period starts. If the actual turns out higher, the report shows a variance, not a new limit. Recalculating after the fact turns control into a formality: the overspend disappears at the moment it needs to be seen.

Does not pass an estimate off as a fact

Where there is no data, there is a “no data” mark, not a plausible figure. Zero and missing data are different claims: zero means “we checked, there were no operations”. Conflating the two produces a confident and wrong report.

Does not draw numbers that do not exist

No “percentage saved”, no “faster period close”, no SLA, no testimonials and no client logos. The numbers in the demonstration on this page are invented and labelled as a demonstration: they show how the panels are built, not the results of a deployment.

Does not close a period with an open reconciliation

A period closes only after reconciliation with an external source and after every unclassified operation has been resolved. A reconciliation with no negative control does not count as a check: it must fail on a deliberately mismatched set.

Does not sign off acceptance of its own work

Self-checking by the executor remains useful, but only the verdict of a role that did not do the work carries weight. A report that never reached independent acceptance does not enter the outcome — for the owner, it simply does not exist.

Questions

What people ask about AI finance

Are the numbers on the dashboard real business data?

No. Every figure in the demonstration was invented by us to show how the panels are built: what ledger reporting by business line looks like, how a balance forecast is drawn, what happens when payments arrive late, and how to read an ageing register. Currency is deliberately left unnamed — these are arbitrary units, not rubles, dollars or anyone’s money. The project has no clients, so there is no real financial data to show, neither ours nor anyone else’s.

Does the finance department already work in the product?

As a VOIR AI product — no. All five functions on this page describe the target architecture: not one of them exists in the product code. Separately, there is the Marisova ecosystem, where cost tracking per task and project, run reporting and generation-budget limits exist as our own internal tools. They are not part of the VOIR AI product and are not provided to clients.

Does the system make payments or move money itself?

No, and that is an architectural constraint rather than unfinished work. The finance loop calculates, compares and warns; moving money stays with a human. A payment, a transfer, a write-off, a limit change and any action in a banking system require the owner’s confirmation. A role cannot raise its own autonomy grade — including the role responsible for finance.

What is a cash gap in this model?

It is a period in which the projected balance falls below a minimum-balance limit that was declared in advance. The key word is projected: the gap is visible before the money runs out, because the payment calendar contains both future receipts and future outflows. The demonstration has three scenarios and only one of them — “Late payments” — takes the balance below the limit. That shows a cash gap is created by mismatched dates, not by the volume of spend.

Where do the spend limits come from?

A limit is set by a human: the owner or someone the owner appointed. The finance role records the limit as a parameter, compares actual spend against it and reports the variance together with a reason, when the reason is visible in the data. The system cannot quietly adjust a limit to match the actual figure — that would turn control into a formality: an overspend would disappear from the report at exactly the moment it needs to be seen.

Which efficiency metrics does the page show?

None. There is no “percentage saved”, no “faster period close”, no SLA, no testimonials and no client logos. The dashboard numbers are demonstrative, and the counters in the text are structural facts: five department functions, four panels, eight departments in the architecture, zero functions implemented in the product. Anything else would be invented, and we are not going to invent deployment metrics for a product that has not launched.

How is the finance department connected to the AI CEO?

The department does not assign itself work. The AI CEO accepts the task and its readiness criteria, distributes the work between the department’s roles — ledger analyst, forecaster and spend controller — folds the result into a report for the owner and decides what changes in the next cycle. The department’s artefacts go through independent acceptance by a QA role that did not run this cycle. Details are on the AI CEO and AI CEO Cycle pages.

Can we connect our bank and our accounting system?

Not now: the VOIR AI product has no integrations with banks, accounting systems or payment services, and we are not writing that they will “appear soon”. Integration is a function of the development department and is described as target architecture. What actually exists today is listed in the status table on this page: it has two columns — “in the VOIR AI product” and “in the Marisova ecosystem” — and the second column is not a promise to a client.

What to read after the finance loop

Money does not exist apart from processes: an obligation arrives from sales, spend arrives from marketing and development, and a constraint on the plan goes to operations. The three pages below show these connections from different sides.

Process

AI CEO Cycle

The five steps inside which the department receives a brief with limits, runs the period, passes independent acceptance and hands the report to the owner.

Open → Where the money comes from

AI Sales

The sales funnel: a deal becomes an obligation, from which the finance loop assembles the invoice register and the due dates.

Open → Where the constraint goes

AI Operations

The execution conveyor: a period with a cash gap becomes a constraint on the plan — dates and resource spend are revised.

Open →

See pricing Ask about the platform