DEV Community: Tali Adler

The Automation Gap Is a Finance Workflow Problem, Not a Spreadsheet Problem

Tali Adler — Sat, 19 Sep 2026 03:02:23 +0000

Recent fintech research has put a useful number on an old frustration: UK businesses are still losing several days a month to manual finance administration. The headline is easy to interpret as a spreadsheet indictment. In practice, spreadsheets are rarely the root cause. The deeper problem is that finance work is a chain of handoffs, exceptions, approvals, and evidence checks that no single system models well.

That distinction matters to engineers building financial products. Replacing a spreadsheet with a dashboard does not remove the work. It often just moves the same reconciliation, chasing, and review tasks into a prettier interface. The better target is the workflow around the number.

The hidden cost is coordination

Consider a routine supplier payment review. Someone downloads a bank statement, someone else checks an invoice, a third person asks whether the purchase was approved, and a manager reviews an exception in a chat thread. The final accounting entry may take seconds. The surrounding coordination can consume hours.

This is why “automation rate” is a weak metric on its own. A process can automatically import 98% of transactions and still feel manual if the remaining 2% are ambiguous, high-value, or impossible to explain later. Those cases create queues, duplicate questions, and last-minute close pressure.

A useful finance workflow should answer four questions for every material decision:

What source records were considered?
What rule or model produced the proposal?
Who reviewed or changed it?
What should happen if the same event arrives again?

The fourth question is the engineering detail that gets missed most often. Financial integrations retry. Webhooks arrive out of order. A bank feed may restate a transaction. Without idempotency and a stable event identity, “automation” can create duplicate work or duplicate entries.

Design the exception path first

A common implementation pattern is to optimize the happy path and add an exception screen later. For finance, reverse that order. Start by defining what an operator needs when the system is uncertain.

An exception record might contain:

{
  "event_id": "bank_2026_09_19_004821",
  "amount": 1840.50,
  "currency": "GBP",
  "candidate_account": "software_expense",
  "confidence": 0.71,
  "evidence": ["bank:004821", "invoice:INV-8821"],
  "reason": "Vendor changed legal name",
  "state": "needs_review"
}

The important fields are not decorative metadata. event_id supports deduplication. evidence lets a reviewer inspect the underlying facts. reason tells the next person why the system stopped. state makes ownership and queue behavior explicit.

A reviewer should be able to accept the proposal, edit it, reject it, or request more evidence. Each action should append an event rather than silently overwrite history. That gives the finance team a usable audit trail and gives engineers a reproducible way to debug production behavior.

Keep automation proposals separate from accounting decisions

AI and rules engines are good at producing candidates. They are less useful when their suggestions are treated as invisible truth. A practical architecture separates three layers:

Observed facts: imported transactions, invoices, contracts, and timestamps.
Proposed interpretation: a suggested match, category, accrual, or anomaly flag.
Accepted decision: the reviewed result that affects the ledger or reporting output.

This separation makes it possible to improve a model without rewriting the company’s history. It also lets a controller ask a precise question: “What did the system suggest on Tuesday, and why did we override it?”

Products such as Portali are interesting in this context because the valuable feature is not merely importing finance data. The useful capability is tying a proposed action to its source evidence and its review state, so an operator can move from “something needs attention” to “here is the decision and why it is safe.” That is a workflow improvement, not a sales promise.

Measure minutes returned to the team

If a finance automation project is working, measure more than straight-through processing. Track:

median time from exception creation to resolution
percentage of exceptions with complete source evidence
duplicate events prevented by idempotency
number of follow-up messages per close item
percentage of accepted proposals later reversed
time spent preparing explanations for reviewers or auditors

These metrics expose whether the system is actually reducing coordination. A lower message count and faster exception resolution may be more valuable than another percentage point of automatic categorization.

The practical takeaway

The current automation gap is not proof that finance teams need one more generic dashboard. It is evidence that financial work needs better representations of uncertainty, ownership, evidence, and decisions.

For engineers, that means treating the exception queue as a first-class product surface, designing for retries from day one, and preserving the difference between a machine proposal and a human-approved accounting outcome. For finance teams, it means asking vendors to demonstrate the review path, not just the import flow.

The spreadsheet is often where the symptoms become visible. The real opportunity is to build a system where every important number has a source, every uncertain interpretation has an owner, and every decision can be explained without reconstructing a week of chat history.

A Better Month-End Starts With Evidence, Not More Checklists

Tali Adler — Fri, 18 Sep 2026 23:01:34 +0000

A Better Month-End Starts With Evidence, Not More Checklists

Month-end close rarely breaks because a team forgot that reconciliation exists. It breaks because the team cannot answer a smaller, more important question quickly:

What evidence supports this number, and what decision did we make about it?

That question is where accounting practice, workflow design, and product engineering meet. A close process can have a hundred checklist items and still leave reviewers hunting through email, spreadsheets, exports, and chat threads. The problem is not a lack of tasks. It is a lack of context attached to each task.

This article walks through a practical pattern for building an evidence-first close workflow. The example is a recurring bank reconciliation, but the same design works for accruals, prepaid expenses, revenue cutoffs, and intercompany balances.

The checklist is not the unit of work

A typical close checklist might say:

Reconcile operating account
Review outstanding items
Post adjusting entries
Obtain approval

Those are useful milestones, but they are poor data structures. They do not tell the next person which statement was used, which period was covered, why an item was left open, or whether the proposed journal entry is still valid.

A more useful unit is an accounting decision with four parts:

Scope: account, entity, and period.
Evidence: the source document, transaction set, or report.
Decision: cleared, accrued, reclassified, deferred, or left open.
Reason: a short explanation that another reviewer can understand.

Once those fields exist, the checklist becomes a view over structured work instead of the place where all context goes to disappear.

A concrete workflow for one reconciliation

Suppose the bank statement shows a $12,400 difference from the general ledger. An evidence-first workflow should not jump directly to “investigate variance.” It should create a review item containing:

{
  "account": "1010 Operating Cash",
  "period": "2026-08",
  "difference": 12400,
  "source": ["bank_statement_2026_08.pdf", "gl_detail_2026_08.csv"],
  "proposed_action": "review",
  "status": "open"
}

The system can then group likely causes: deposits in transit, outstanding checks, bank fees, timing differences, or coding errors. Automation is helpful here, but it should produce a proposal, not pretend that a pattern match is an accounting conclusion.

A reviewer might accept a $9,800 deposit in transit, identify a $2,400 bank fee, and reject a suggested reclassification for the remaining $200. Each outcome should remain attached to the same evidence bundle. That gives the close a durable trail: what was observed, what was proposed, what changed, and who accepted the decision.

Design the exception path first

The happy path is easy to demo. The exception path is what determines whether a finance workflow earns trust.

For every automated suggestion, define at least three outcomes:

Accept: the evidence is sufficient and the proposed treatment is correct.
Edit: the suggestion is useful, but an amount, account, or explanation needs changing.
Reject and explain: the suggestion is not appropriate, with a reason that improves future review.

This is more useful than a binary approved/rejected flag. It also makes metrics meaningful. You can measure how often proposals are accepted unchanged, how often they need edits, and which source types create the most review work. Those measurements tell you where to improve mappings and controls.

In a tool such as portali.tech, the valuable feature is not simply that a document can be uploaded or a task can be assigned. It is the connection between source evidence, proposed treatment, and explicit human review. That connection reduces the time spent reconstructing history when a controller asks, “Why did we book this?”

Keep automation idempotent

Close workflows are often rerun. A bank feed may refresh, a file may be uploaded twice, or a reviewer may reopen a period after a correction. If each run creates a new journal proposal, the system quickly becomes noisy and unsafe.

Use a stable key for each proposed item, such as:

company + account + period + source_transaction_id + rule_version

On rerun:

update an existing open proposal when the source is unchanged;
create a new revision when the source or rule version changes;
never silently overwrite an accepted decision;
preserve the previous explanation when a new reviewer takes over.

This is ordinary application engineering, but it has an accounting consequence: reproducibility. A reviewer should be able to see why the system showed a different proposal yesterday without guessing which process ran in the background.

Make the review queue useful

A queue sorted only by creation time is not a close workflow. Prioritize by risk and aging. A simple score can combine materiality, days outstanding, account sensitivity, and confidence in the proposed match:

priority = materiality_weight
         + aging_weight
         + sensitivity_weight
         - confidence_weight

The exact formula is less important than making it visible and adjustable. A $200 item in a high-risk revenue account may deserve attention before a $5,000 routine timing difference in cash.

The queue should also show the reviewer what they need without another search: the evidence links, the proposed entry, the matching transactions, prior decisions for similar items, and the next action. Good workflow design removes navigation, not judgment.

A close that can explain itself

The strongest month-end process is not the one with the most automation. It is the one that can explain each material number with less manual archaeology.

Start small: choose one account, capture the evidence and decision fields, add accept/edit/reject outcomes, and make reruns safe. Then measure review time and recurring exception types before expanding to another account.

Checklists still matter. They tell the team what should happen. Evidence-linked decisions tell the team what actually happened. That distinction is the difference between a close that merely reaches a deadline and a close that remains understandable after the people who performed it have moved on.

The Close Starts With a Question: Building Source-Linked Accounting Workflows

Tali Adler — Fri, 18 Sep 2026 21:05:27 +0000

The close starts with a question: building source-linked accounting workflows

Month-end close rarely breaks because someone cannot add two numbers. It breaks because a number arrives without enough context. A balance changed, a payment was matched, or an accrual was posted, and three days later nobody can answer a simple question: what evidence supports this?

That question is where accounting software and engineering software increasingly meet. The useful automation is not just a bot that creates journal entries. It is a workflow that keeps the source, decision, reviewer, and final output connected.

This article walks through that pattern using a common pain point: reconciling a high-volume account when the underlying transactions come from several systems.

The hidden cost of an unlinked reconciliation

Imagine a reconciliation ending with this row:

Account: Operating cash
Period: August 2026
Difference: $18,420.00
Status: Resolved

The row looks finished, but it is not very useful. Resolved by whom? Which bank statement line was involved? Was the difference a timing item, a duplicate, or a manual adjustment? Is there a supporting document? Can another reviewer reproduce the conclusion?

When that context lives in email, spreadsheets, and chat, every review becomes archaeology. The team may still close on time, but the process gets slower and riskier each month.

A better design treats every material accounting decision as an object with a small audit trail:

{
  "account": "Operating cash",
  "period": "2026-08",
  "amount": 18420.00,
  "source_refs": ["bank:stmt-2026-08-31", "erp:batch-8841"],
  "proposed_reason": "Timing difference",
  "confidence": 0.87,
  "reviewer": null,
  "decision": "pending"
}

The important fields are not fancy. They make the work inspectable.

A practical pattern: source, proposal, decision

The most useful workflow I have seen separates three stages.

1. Source

First, preserve the inputs exactly as received. Store the statement line, ledger transaction, invoice, payment record, or API response with a stable reference. Do not overwrite the original value when normalizing it. Keep both the raw representation and the fields used for matching.

This is the accounting equivalent of immutable event data. If a parser improves next month, you can reprocess the original input rather than trying to reconstruct it from a spreadsheet.

2. Proposal

Next, let rules or an AI-assisted process propose a match or explanation. A proposal should include the reasoning signals, not just a label. For example:

amount matches within a defined tolerance
transaction dates are within five business days
counterparty names normalize to the same vendor
a related invoice is already approved

A proposal is not a posting. That distinction matters. It gives the system permission to be helpful without giving it permission to silently change the books.

3. Decision

Finally, a person or an explicit policy makes the decision. Record who approved it, when, what changed, and which evidence they reviewed. If the proposal was rejected, preserve that rejection too. Negative decisions are valuable training data and valuable audit evidence.

This model also makes idempotency easier. A retry can safely regenerate a proposal because the decision is a separate state transition.

Where Portali fits

A feature spotlight for portali.tech is its source-linked way of organizing accounting work around the item that needs a decision, rather than around a collection of disconnected files. The practical benefit is small but important: a reviewer can move from a flagged transaction to the supporting context without asking someone to find an attachment or explain which spreadsheet tab is current.

That is especially useful for teams that have outgrown manual checklists but are not ready to replace every system of record. The accounting platform can remain the place where entries are posted. The workflow layer can make the path to that entry visible and reviewable.

The design principle is worth borrowing even if you build the tooling yourself: automate the gathering and comparison of evidence, but keep the accounting decision explicit.

Implementation details that prevent future pain

Use stable identifiers

Display names change. Vendor names are corrected. Bank descriptions are inconsistent. Match on stable source IDs whenever possible, and keep a human-readable label only for display.

Make transitions append-only

Instead of changing pending to approved with no history, append a decision event:

{
  "work_item": "recon-18420",
  "from": "pending",
  "to": "approved",
  "actor": "j.smith",
  "at": "2026-09-01T14:32:11Z",
  "note": "Bank settlement posted one day after period end"
}

Append-only history is easier to audit and easier to debug than a single mutable status field.

Put limits around automation

Define thresholds before turning on auto-approval. For example, auto-match only when the amount, currency, source account, and counterparty all agree. Route anything outside that policy to review. An AI suggestion can improve prioritization, but it should not quietly expand the policy.

Measure review quality, not only speed

Track the percentage of items resolved without rework, the age of open exceptions, the number of proposals rejected, and the time from source arrival to approved decision. A faster close with more unexplained adjustments is not an improvement.

The payoff

Source-linked workflows change the close from a race to collect screenshots into a sequence of explainable decisions. Engineers get clear state transitions and retry behavior. Accountants get evidence in the place where the question is being answered. Managers get a better view of what is truly complete.

The best accounting automation is not the system that removes every human touch. It is the system that makes each remaining human touch focused, informed, and easy to verify.

The Fed Just Moved Rates. Your Finance Automation Needs a Better Event Model.

Tali Adler — Fri, 18 Sep 2026 19:01:00 +0000

The Fed Just Moved Rates. Your Finance Automation Needs a Better Event Model.

A rate decision is usually discussed as a macroeconomic event: the central bank changes its target range, markets reprice, and businesses revisit forecasts.

For finance and accounting systems, it is also an operational event.

On September 16, 2026, the Federal Reserve raised its benchmark target range by 25 basis points to 3.75%–4%, according to reporting from CNBC. The interesting engineering question is not whether a company should predict the next move. It is how software should turn a public rate change into a controlled, reviewable set of accounting and finance actions.

That distinction matters. A spreadsheet can absorb a new assumption in seconds. A production finance workflow has to answer harder questions:

Which instruments and schedules are actually affected?
Which rate source was used, and when was it retrieved?
Is the new value an observed fact, an approved assumption, or a forecast?
Which journal entries, disclosures, and cash forecasts need review?
Can another person reconstruct the decision three months later?

This is where event-driven design meets accounting discipline.

Treat the announcement as an immutable event

The first mistake is overwriting a setting such as base_rate = 4.00. That destroys context. Instead, store the announcement as an immutable event with enough metadata to reproduce the calculation.

A minimal event might look like this:

{
  "event_type": "central_bank_rate_decision",
  "effective_date": "2026-09-17",
  "announced_at": "2026-09-16T18:00:00Z",
  "jurisdiction": "US",
  "target_lower_bound": 3.75,
  "target_upper_bound": 4.00,
  "unit": "percent",
  "source_url": "https://www.federalreserve.gov/",
  "source_retrieved_at": "2026-09-18T08:15:00Z"
}

The event is a fact. A company’s selected discount rate, borrowing forecast, or cash-planning assumption is a separate object derived from that fact. Keeping those layers separate prevents an automation from presenting a judgment call as if it came directly from the Fed.

It also makes corrections safer. If the source parser was wrong, you can invalidate or supersede one event without rewriting every downstream record.

Build a dependency graph, not a giant “recalculate” button

A rate change rarely affects everything. It affects specific contracts, accounts, models, and reporting outputs.

Model those relationships explicitly. For example:

rate decision
  -> variable-rate credit facility
      -> next interest accrual
      -> cash forecast
      -> covenant dashboard
  -> lease or valuation model
      -> discount-rate review task
  -> treasury report
      -> management commentary draft

Each edge should carry a rule and an owner. A variable-rate loan may be eligible for automatic recalculation because its contract says SOFR plus a fixed spread. A valuation model may only create a review task because the discount rate is a policy decision, not a mechanical pass-through.

This design gives you a useful middle ground between manual work and reckless automation: calculate what is deterministic, route what requires judgment.

Separate calculation from approval

A reliable workflow should produce a proposed result before it posts anything consequential.

For an interest accrual, the calculation service can produce:

principal: 2,000,000
spread: 2.25%
reference rate: 4.00%
annualized rate: 6.25%
days in period: 30
proposed interest: 10,274.00

The approval layer then checks the contract, day-count convention, effective date, and materiality threshold. If the result passes policy, it can be posted automatically. If not, the system creates an exception with the inputs attached.

This is more than a control requirement. It is a debugging strategy. When finance users question a number, they need the exact inputs and rule version that produced it, not a black-box statement that “the system recalculated.”

Make freshness and provenance visible

Public financial data has a lifecycle. A source may publish a decision, revise a page, or expose the same number through several feeds. Your workflow should record:

The canonical source URL.
Retrieval timestamp.
Effective timestamp.
Parser or connector version.
Normalized value and original text.
The downstream jobs triggered by the event.

A small provenance record can prevent a large reconciliation problem. It also lets an engineer distinguish a stale input from a broken calculation.

When you display the result, show freshness next to the number. “4.00%, retrieved 08:15 UTC, effective Sept. 17” is much more useful than “current rate: 4.00%.”

Use idempotency everywhere

Central-bank announcements are likely to arrive through more than one path: an API poll, an email parser, a news feed, or a human upload. Your consumer must assume duplicates.

Create a stable idempotency key from the jurisdiction, event type, effective date, and normalized decision identifier. Every downstream action should also have its own key, such as:

interest-accrual:loan-1842:2026-09-17

If the event is delivered twice, the system should not double-create a journal entry or send two review requests. Store the processing status and the input event ID with each action so operators can inspect what happened.

What a practical close checklist looks like

For the next month-end close, a rate-event workflow can create a focused checklist:

Refresh variable-rate debt schedules.
Compare calculated interest with lender statements.
Review cash forecast assumptions.
Identify models using policy-controlled discount rates.
Attach source and effective-date evidence to the close package.
Route exceptions with a named owner and due date.

That checklist is small enough to operate and specific enough to audit. It avoids the common failure mode where “macro update” becomes an unbounded task assigned to the entire finance team.

Tools such as portali.tech are useful in this layer when they connect operational data, accounting work, and review evidence in one workflow. The value is not a flashy prediction. It is giving the team a traceable path from external event to proposed action to approved result.

The engineering takeaway

A rate decision is not just a number to copy into a dashboard. It is a time-stamped event with uncertain downstream scope.

Design the system around that reality: preserve the source event, model dependencies, calculate deterministically, ask for approval where judgment is involved, expose provenance, and make every consumer idempotent.

That approach works for central-bank rates, tax notices, payment-provider changes, and other external facts that quietly change accounting operations. Good finance automation does not erase the chain of reasoning. It makes the chain easier to follow.

The Exception Queue Is the Real Product in Accounting Automation

Tali Adler — Fri, 18 Sep 2026 15:00:50 +0000

The Exception Queue Is the Real Product in Accounting Automation

Most accounting automation demos focus on the happy path: connect a bank feed, watch transactions get categorized, and admire a clean reconciliation screen. The interesting engineering problem starts after that demo. What happens when the confidence is low, the invoice is missing, or two source systems disagree?

That is why an exception queue is more than a feature. It is the control surface that makes automation usable in a real accounting workflow.

Why the happy path is not enough

A transaction can look simple while carrying several possible meanings. A payment to a software vendor might be a subscription, a prepaid expense, a contractor charge, or a duplicate. A transfer may be a legitimate movement between accounts, or it may be an unexplained deposit. The ledger often does not contain enough context to decide safely from one row alone.

A production system should not hide that uncertainty behind a confident-looking category. It should preserve the evidence, state what it believes, and make the next human decision cheap.

This is the difference between automating data entry and automating a workflow. The first moves values around. The second helps a team decide what is safe to approve.

The shape of a useful exception queue

A useful queue answers five questions for every item:

What needs attention? Show the transaction, amount, date, proposed account, and confidence or rule that caused the item to be routed.
Why was it flagged? Explain the mismatch in plain language: missing invoice, conflicting vendor, unmatched amount, duplicate candidate, or policy violation.
What evidence is available? Put the bank line, invoice, statement, prior mappings, and related ledger entries in one review context.
What decision can I make? Offer a small set of explicit actions such as approve, change category, link evidence, split, or defer.
What happens next? Make the downstream effect visible before the reviewer commits the change.

That last point matters. An approval should not feel like editing a spreadsheet cell. It is a controlled transition in an accounting process.

Portali's review-first approach

Portali's workflow is built around this review-first model. It ingests bank feeds, statements, and uploaded documents, then uses accounting-aware categorization and three-way matching across statements, invoices, and ledger activity. Items that match cleanly can move through the workflow. Uncertain items are surfaced in an exception queue for review instead of being silently posted.

The practical benefit is not simply fewer clicks. It is a better allocation of attention. A bookkeeper can spend time on the 12 transactions that require judgment instead of rechecking all 1,200 transactions because the system gives no clear boundary between automated work and reviewed work.

The same design also helps teams scale. A shared queue makes ownership visible, while approval rules and internal controls keep a reviewer in the loop where the risk is material. The audit trail then records what was suggested, what changed, who approved it, and when. That context is valuable at month-end and even more valuable when someone asks about a transaction several months later.

A concrete implementation pattern

If you are building a similar system, model an exception as a first-class object rather than a boolean on a transaction. At minimum, store:

a stable transaction identifier
the exception type and severity
the proposed action and its evidence
the rule, model result, or comparison that produced the flag
an owner and review state
a decision, reviewer, and timestamp
links to related documents and ledger entries

Keep the original inputs immutable. Store new suggestions and decisions as events or revisions. This makes it possible to reconstruct the state of the books at a point in time and prevents a corrected value from erasing the reason a prior value was accepted.

For ranking, start with risk and aging rather than model confidence alone. A low-value duplicate may be less urgent than a high-value unmatched payment close to the reporting deadline. A simple priority score can combine amount, close date, exception severity, client policy, and how long the item has waited.

Measure the queue, not just the model

Accuracy is necessary, but it is not the only useful metric. Track:

auto-clear rate by exception type
reviewer minutes per resolved item
first-pass approval rate
aging of unresolved exceptions
reversals after approval
percentage of items with complete evidence

These metrics expose whether automation is actually reducing operational load. A high auto-clear rate paired with a rising reversal rate is not a win. Neither is a queue that is technically small because uncertain items are being posted without review.

The broader lesson

Good accounting automation does not pretend judgment has disappeared. It separates repeatable work from consequential decisions, then gives people a focused place to handle the edge cases. That is a product principle, a data-modeling principle, and a trust principle at the same time.

The exception queue is where an accounting system proves it understands the difference between a suggestion and a decision. Build that surface well, and automation becomes something a finance team can supervise. Build only the happy path, and every shortcut eventually returns as a manual cleanup project.

How AI Agents Are Quietly Taking Over Month-End Close

Tali Adler — Fri, 18 Sep 2026 12:24:01 +0000

Month-end close used to be a rite of passage: spreadsheets open on three monitors, a folder of bank PDFs, and that one transaction nobody can explain. In 2026, that ritual is being quietly automated — not by a single magic tool, but by AI agents doing the boring parts one at a time.

What the agents actually do

The modern close pipeline looks less like data entry and more like a queue of specialized jobs:

Transaction matching. Bank feed lines get matched to ledger entries using semantic similarity, not exact-string rules. An agent reads the memo text, the counterparty, the amount, and the date, then classifies the match as confident or needs-review.
Exception surfacing. Instead of a human scanning 2,000 rows, the agent surfaces the 12 that actually need judgment: duplicate charges, unclassified merchants, timing gaps.
Categorization. New vendors get bucketed into your chart of accounts based on how similar past spend was treated.
Report drafting. Once the books reconcile, the same agent assembles the P&L and cash-flow summary with the variances already annotated.

The pattern is always the same: agents compress the mechanical middle, and humans keep the first and last mile — defining policy and making the judgment calls.

Why this works now, and didn't in 2020

Bank feeds got reliable, LLMs got cheap enough to run against thousands of transactions per day, and the reconciliation problem itself turned out to be mostly a classification problem. That last point is underrated: once you frame 'does this bank line match this ledger entry' as a similarity-and-confidence question, it becomes an AI problem instead of a human-tolerance problem.

What good looks like

A well-run agent-assisted close has three properties:

Everything is traceable. Each automated match links back to its evidence. If your tool can't explain why a transaction was matched, that's a red flag.
Humans see the exceptions, not the whole ledger. Review effort should scale with ambiguity, not volume.
The close gets faster every month. Auto-match rates improve as the system learns your vendor history.

Where this is heading

The next step is agents that don't just close the books but continuously reconcile — daily, not monthly. Continuous reconciliation kills the month-end crunch entirely, because there's no pile to process if you never let the pile form.

At Portali (portali.tech) we're building exactly this hybrid world: human accountants and CPAs get automation for their practice, and AI agents get an API to do accounting work on behalf of their users. If you're building in fintech, the interesting design question right now isn't 'can an agent do bookkeeping' — it's 'how do you make its work auditable enough that a human will sign it.'

That question is where the next five years of this industry live.