How Fiskl’s AI Works, From Every Transaction to the Close

By Shawn Vader, CTO and Co-Founder, Fiskl

Fiskl is a global, AI-native accounting platform for small and medium-sized businesses and the accounting firms they work with. This post explains how its AI is built. It follows one transaction from the bank feed into the ledger, and one month from the first open exception to the locked period. Along the way, it shows which component makes each decision and how every change stays traceable.

Fiskl’s AI works in two layers. The infrastructure layer runs the accounting continuously, with no agent needed. Agents take on the work that needs investigation and planning across several steps. Both layers work on the same ledger and under the same controls. The full technical reference is on Fiskl’s help site: How Fiskl AI Works.

Each component has one job

Fiskl assigns each kind of problem to the component built for it.

Component	What it is responsible for
Proprietary decision models	Classifying transactions, matching payments, reading documents and detecting anomalies
Financial context and retrieval	Supplying the records, relationships and guidance a decision needs
External language models	Broader reasoning and language understanding, returned as suggestions
Orchestration, including Fi	Choosing the models and tools for a multi-step task and coordinating them
Policy and execution controls	Deciding whether and how an action may proceed
Deterministic accounting engine	Every accounting calculation and every ledger rule
Ledger and audit records	The authoritative financial record and the evidence behind each change

Layer one: the infrastructure runs the accounting

From bank line to ledger

Fiskl has 21,000+ bank and financial institution connections. A transaction from a bank feed enters the ledger, and matching runs first. If it matches an open invoice, bill, payment or transfer, Fiskl links it to that record. Reconciliation runs continuously.

Every other transaction goes through Fiskl’s decision system in a fixed order. The first source that can place the transaction decides it.

• Rules decide first. A rule is the system’s permanent memory for a merchant. Fiskl proposes rules from decisions you confirm, and you can create your own.
• History decides next. If you have confirmed the same merchant before, the system repeats your decision.
• Fiskl’s models decide the rest. AI Categorization is on by default. Each assignment carries a confidence level.

Rules and history make results repeatable. The same transaction gets the same answer every time.

Confidence sets the order of review

Every categorization applies automatically as the transaction enters the ledger. A confidence level marks each one. Green is 80% and above. Amber is 60% to 79%. Red is below 60%.

Amber and red transactions are already categorized. The confidence level tells your team where to look first, starting with red. You can correct any categorization and mark it as finished once verified.

Each categorization also sets the tax rate and attaches the client or vendor. Rules and account defaults set them too, and a rule decides first when it applies.

What the models are trained on

Fiskl’s decision models are trained on more than 500 million accountant-certified transactions. They handle the high-frequency work: classification, payment and invoice matching, reconciliation, document understanding and anomaly detection. Categorization accuracy reaches up to 98%. Fiskl measured it over 16 months in collaboration with 37 accounting firms.

A small share of transactions stays unresolved after Fiskl’s own models have run. For those, an external language model can suggest a treatment. The suggestion carries the same confidence levels and accounting controls. This step is optional. You can turn it off in Settings > AI & Automations.

External models are interchangeable components. Fiskl can replace or upgrade them without changing the ledger or the accounting rules.

Context behind every decision

Accounting data is relational. A single vendor payment can connect to the bill, the matching bank transaction, the vendor’s history, a currency conversion, a tax treatment and the resulting journal entries. Fiskl assembles that context before a decision is made.

Retrieval-augmented generation brings authoritative guidance into the reasoning, such as tax rules and accounting documentation. Fiskl keeps jurisdiction-specific tax knowledge current through scheduled updates. The ledger stays the authoritative record. The context layer is a structured view of its relationships.

The deterministic engine does every calculation

AI reasoning is probabilistic. Fiskl keeps every accounting calculation in a deterministic engine, so the figures are exact.

The engine calculates journals, tax and FX. That includes realized and unrealized gains and losses and period-end revaluation. It also covers double-entry validation, receivables and payables, inventory and cost of goods sold, and fixed assets and depreciation. Revenue recognition, period locks and financial reporting under supported GAAP and IFRS requirements run there too. The engine validates each entry before it is saved.

The models interpret evidence and propose a treatment. The engine applies the accounting rules in code. Its results are exact and repeatable. Each entry traces back to its source documents and transactions, so the ledger stays auditable.

The learning loop

Your own history adapts straight away. Finish a transaction, and history repeats your decision for that merchant’s next transactions. Finish the same merchant the same way twice, and Fiskl proposes a rule. Approve the rule, and future transactions from that merchant arrive categorized and finished.

Only finished transactions teach history and rule suggestions. An unconfirmed prediction never becomes the answer for later transactions.

Fiskl’s own models improve under control. A correction updates the record and also becomes a feedback signal. The signal holds the original prediction, its confidence, the transaction context, the correction and the verified treatment. Fiskl validates these signals against ledger outcomes and evaluates them to find recurring errors and weak classifications.

Each model update is tested against evaluation datasets, error metrics and regression tests. It is approved before release. A single correction never changes a production model directly. The same feedback also improves context retrieval, model routing, confidence calibration and exception handling.

Fiskl never sells data or provides it for third-party model training.

Layer two: agents take on investigation

Some work needs more than a single decision. A problem has to be found, traced, corrected and then verified. Agents take on that work.

Agents use the same accounting capabilities as the rest of the platform. Fiskl exposes those capabilities as defined, permission-controlled tools. They include classifying transactions, matching incoming payments to invoices, reconciling accounts, retrieving statements and balances, and creating or updating permitted records.

Worked example: a payment that has not reconciled

1. Fi or an automated workflow identifies the request and the affected records.
2. Fiskl assembles the payment, related invoices, bank transactions, documents, currency information and accounting history.
3. Matching models evaluate possible relationships and return candidates with confidence signals. Broader reasoning is used where needed.
4. Fiskl checks the proposed treatment against accounting rules, permissions, period locks and approval requirements.
5. The deterministic engine applies the authorized match or change.
6. Fiskl checks the resulting ledger state and records the action with its evidence.
7. The outcome, including any correction, feeds Fiskl’s evaluation process.

The Fi Close Agent

The Fi Close Agent runs the month-end close. It is live with selected accounting firm partners. It starts from a ledger that Fiskl’s AI has already categorized, matched, reconciled and revalued. Its work is the exceptions.

The agent first confirms that each bank feed has delivered transactions up to month end. A feed that is behind becomes a blocked task, and the agent carries on with everything else. Its checks then cover:

• Bank reconciliation
• Uncategorized and low-confidence transactions
• Transfers between the company’s own accounts
• Client payments against open invoices
• Asset purchases with no asset record
• Missing vendor bills
• Tax coding
• Possible duplicates
• Expected adjustments, such as accruals and prepayments

A final ledger check and the trial balance close every pass.

Each finding becomes a task. The agent traces the exception to its supporting transactions and documents. It then prepares a proposal. The proposal previews the entry with its ledger accounts, amounts, currency, tax rate and date. It states the reason in plain language and links to the strongest evidence.

The approver approves, edits or rejects each proposal. Once a proposal is approved, Fiskl records the change through the same engine as a change a person makes. The agent reruns the check. A task closes only when its check passes.

The agent decides what to propose and explains why. The engine calculates the amounts, tax and currency conversion. The agent never guesses a ledger account, a tax rate, a document or a materiality threshold. When one is missing, it asks, and the task waits.

If the records behind a proposal change before approval, the agent withdraws it and prepares a new one. A reversal is a new proposal, approved like any other, and the original change stays in the audit trail. When every task is done and the final checks pass, the agent proposes locking the month. The accountant authorizes the lock. The Fi Close Agent guide lists every check it runs.

Fi, the orchestrator

Fi, Fiskl’s AI CFO, is the conversational and agentic interface to the same infrastructure. It works in over 200 languages. Fi interprets a request, plans the workflow, retrieves the information and invokes Fiskl’s accounting capabilities.

A request to explain why cash flow fell this month shows how this works. Fi retrieves current and historical data. It examines receivables, payables and cash movements. It compares periods and pulls the supporting transactions. It then evaluates the possible explanations and prepares recommendations.

On the Prime plan, Fi also corrects or records entries on the user’s instruction. It does this within that user’s permissions.

How people stay in control

Reasoning and execution are separate responsibilities in Fiskl. An AI recommendation needs permission before it becomes an action.

Permissions

AI actions operate within the permissions of the user or integration behind them. The Fi Close Agent never makes a change that the approver could not make in Fiskl. If an approver lacks a permission, the Approve button shows a lock and the reason.

Approvals

Where approval is required, a prepared entry waits for an authorized user before it is recorded.

Period locks

Fiskl blocks AI changes inside a locked accounting period until an authorized person unlocks it. Categorization of a transaction dated inside a locked period waits until the lock moves. The Fi Close Agent leaves locked and filed periods unchanged. A task that would need to change one is marked Blocked, with the reason.

The Audit Log

Fiskl records each financial change and its origin, including user actions, AI actions and request IDs. A request ID links all the changes that belong to one recorded action. Every automated categorization appears as a System change, naming the process responsible. Every record the Fi Close Agent changes shows who approved it and links to the task.

Bring Your Own AI uses the same tools

Bring Your Own AI (BYOAI) connects your preferred AI to your Fiskl data through Fiskl’s MCP server at https://my.fiskl.com/mcp. You sign in to Fiskl and review the access your preferred AI requests on a consent screen. You can clear any permission before you approve. Reading and changing are separate permissions, so you can start with read access.

A connected AI reads financial data and carries out supported accounting actions. It can also run close automation, as Fi can. Your Fiskl permissions are the ceiling, and every request is checked against them at the time it is made. Reports, tax rates and the Audit Log are read-only.

Sensitive administrative actions stay out of reach whatever you approve. These include managing team members, changing the subscription, creating API keys, editing payment instructions on invoices, creating manual journals and changing bank connections. A connected AI cannot delete records. Every change it makes is recorded in the Audit Log with who made it, which AI they used, when, and the record affected. To set it up, see Connect your preferred AI to Fiskl.

Two layers, one ledger

Both layers work on the same ledger, under the same permissions and the same Audit Log. Fiskl serves more than 82,000 customers globally. It is live in 200+ countries, with 170+ currencies and 21,000+ bank and financial institution connections. Its customers trade locally, across borders or both.

Start for free