DEV Community: Tali Adler

My Clients Now Arrive With Their Own AI Advisor (And I Think That's a Good Thing)

Tali Adler — Thu, 22 Oct 2026 16:56:43 +0000

Something interesting started happening between me and my clients. Lately, I receive emails from clients telling me what their AI assistant thinks I should do. Not just questions. Sometimes answers, explanations, even instructions. And I find this fascinating.

For years, clients came to accountants for information, guidance, and professional advice. Now, some arrive with their own AI advisor. I think that's a good thing: clients are becoming more informed, more involved, and more willing to explore possibilities.

What changes when both sides have AI

When both my client and I have access to AI, the fair questions become uncomfortable: what exactly changes in our relationship? What am I really bringing to the table? What new value could I offer that wasn't possible before?

Perhaps the opportunity isn't simply to use AI to do the same work faster. Perhaps it's to combine stronger technology with a better understanding of what clients actually need. To rethink not only how we work, but what we can make possible for them.

The bigger shift hiding in plain sight

Here is the part I find most interesting. If the books live where the client already is, inside the AI assistant they use every day, then the client's AI and their accountant can work on the same numbers at the same time, instead of emailing exports back and forth.

That changes the workflow at its root:

No more exporting transactions and re-entering them in a second tool.
No more reconciling against a stale snapshot of the bank feed.
Exceptions surface early, while they are still cheap to fix.
The accountant stops being a data-entry cleanup crew and starts being the judgment layer.

Where Portali fits

This is exactly the direction we are exploring with Portali. Portali is agentic accounting software that connects to ChatGPT via MCP, with Tali, the AI assistant, handling the repetitive layer: syncing bank feeds, matching transactions, and flagging exceptions for your review. The client asks questions in ChatGPT; the accountant sees clean, current books. Both sides of the table finally work on the same source of truth.

No neat conclusions yet

I don't have all the answers, and I'm not in a hurry to pretend that I do. But I see this as an opportunity to grow, both professionally and in the value I bring to my clients. We are only beginning to discover what this new kind of partnership could look like.

I Don't Want to Spend Less Time Being an Accountant

Tali Adler — Tue, 20 Oct 2026 14:58:41 +0000

I don't want to spend less time being an accountant. I want to spend less time on everything that keeps me from being one.

The balance quietly reversed

Early in my career, roughly 30% of my working hours went to internal office tasks. The other 70% went to clients, meetings, relationships, and building the practice. Over the years that balance flipped. Now it can feel like 80, even 90 percent of the week goes into managing the work itself:

regulations and reporting requirements
software logins and technical issues
the endless challenge of finding and training good people

Even client contact changed. Zoom made communication easier, but in-person meetings became rarer. We have more tools than ever, and somehow less time for what matters most.

The part I still love

And yet I still genuinely enjoy being an accountant. Understanding a business, untangling a problem, helping a client move forward. That is the job I signed up for. What I don't love is the pile of administrative work that sits between me and it.

Why this moment is different

Every previous wave of software made the same old processes a bit faster. What's changing now is the layer of work agentic systems can absorb entirely: categorizing transactions, reconciling accounts, chasing missing documents, closing the month. Not a faster checklist — fewer items on the checklist. The judgment work goes back to humans, where it belongs.

Imagine spending less time managing documents, systems and routine tasks, and more time actually working with clients. More conversations. More opportunities. More room to grow the practice.

How we're building this at Portali

I'm not looking for technology to replace professional judgment or personal relationships. I'm looking for technology that gives us more time to use both.

That's exactly what we're building at Portali: connect your books once, then run reconciliation, reporting and month-end conversationally through ChatGPT via MCP, with you staying in control of every judgment call.

The future of accounting isn't about doing more work with fewer resources. It's about having more time to do the work that really matters.

My books just reconciled inside ChatGPT

Tali Adler — Sat, 17 Oct 2026 14:17:16 +0000

Wait... Look! Look at that!! My books just reconciled inside ChatGPT!!

I connected ChatGPT to Portali over MCP and asked it to work through my books. Portali synced the feeds, matched the transactions and flagged exceptions for my review. A human still approves what gets flagged, so nothing posts silently.

Watch the 8-second clip: https://youtube.com/shorts/DKCM0fv-cAQ

Try it: https://portali.tech/?utm_source=devto&utm_medium=organic&utm_campaign=oct17-reconciled-in-chatgpt

bookkeeping #accounting #chatgpt #ai #monthend

I connected Portali to ChatGPT and filmed a day in my life

Tali Adler — Fri, 16 Oct 2026 06:31:19 +0000

We connected Portali (agentic accounting software with MCP integration) to ChatGPT and filmed what a normal day looks like when reconciliation is not on the to-do list.

The old workflow

Export from the accounting tool. Paste into a spreadsheet. Cross-check against the bank feed. Fix the duplicates. Repeat every single week.

What changes

With Portali handling the workflow, you ask the assistant (Tali) and the reconciliation just runs. The video shows the boring truth of that: coffee, a walk, a chat window, done.

What is the one task you would delete from your week? That question is literally on the end screen of the video — answer it in the comments here or on YouTube.

Try the workflow yourself: portali.tech

Portali is agentic accounting software with MCP integration. Tali is the AI assistant that runs the workflows.

The 2 AM text that found a $2,340 double charge

Tali Adler — Mon, 12 Oct 2026 17:45:45 +0000

A founder texts an accounting agent at 2:07 AM: "did we pay the vendors??"

The reply comes back in seconds: "Yes. Also, you were double-charged $2,340. Refund already requested."

That 8-second exchange is the whole pitch for agentic accounting, so here is what has to be true behind it.

The workflow behind the text

Ingest payments continuously. Bank feeds and card transactions land in one ledger instead of living in exports.
Match vendor bills to payments. Every payment is paired with the invoice it settles.
Flag anomalies. Two charges, same vendor, same amount, close dates: duplicate candidate.
Act, then report. The agent drafts the refund request and tells you after, with the evidence attached for review.

Nothing exotic. It is the reconciliation a bookkeeper does at month-end, run every night instead.

Why legacy tools miss it

Legacy software makes you export, re-enter and reconcile by hand. A duplicate charge sits in a CSV until someone has the hour to scan it. By then the refund window may be closing.

Where MCP fits

Portali supports MCP integration, so the agent reads and acts on the ledger through a standard interface rather than screen scraping. The workflow comes first; MCP is just how the agent gets safe access to your data.

Meet Tali, the AI assistant on the other end of that text, and see the reconciliation workflow: portali.tech

Export, Re-Enter, Reconcile, Repeat: Breaking the Month-End Habit

Tali Adler — Wed, 07 Oct 2026 14:43:56 +0000

If you run month-end in traditional accounting software, you know the loop:

Export the ledger to a spreadsheet. Re-enter or re-map the bank data. Reconcile line by line. Do it all again next month.

The data already existed in your software. The software just was not built to connect the two ends. That is the gap most "automation" never touches, and it is why the close still eats a week.

What the pain actually looks like

Duplicate exports: the same transactions, cleaned up by hand, every single month
Stale cash data: by the time the reconciliation is finished, the picture is already old
Review by memory: nothing tells you why a match was right, so you check it anyway

The workflow we built instead

Portali is agentic accounting software, and Tali is the AI assistant inside it. In practice the month looks like this:

Connect your bank feed. Transactions flow in on their own.
Tali matches them against your books and attaches the evidence behind each match.
You review the exceptions and approve. Tali never quietly decides for you.
Ask questions in plain English: cash position, open items, unusual categories. You get answers, not a spreadsheet hunt.

The boring, repetitive part is handled. The judgment calls stay yours.

Where MCP fits

Portali speaks MCP (Model Context Protocol), so the AI agents you already use can read transactions, run reconciliations and query your books through a standard interface. No screen-scraping, no one-off integrations. It is plumbing, not the headline. The headline is that the month-end loop above stops being your job.

Who it is for

CPAs and bookkeepers who want faster closes without losing control
Small business owners tired of re-entering data their software already has
Developers building finance agents that need reliable access to real books

The 17 second overview

See the reconciliation workflow: portali.tech

The Missing Layer in Accounting Automation: A Reviewable Evidence Trail

Tali Adler — Mon, 21 Sep 2026 15:01:45 +0000

The Missing Layer in Accounting Automation: A Reviewable Evidence Trail

Most accounting automation demos stop at the impressive part: a system reads a document, extracts a value, and proposes an entry. That is useful, but it is not the hard part of operating finance software. The hard part is making the proposal reviewable after the context has disappeared.

A month later, someone needs to answer simple questions: Which source created this number? What did the system infer? Who approved it? What changed between the first suggestion and the final posting? If the answer is a screenshot, a spreadsheet cell, or a vague log message, the workflow is fast only until the first audit question.

This article describes a practical design for an evidence-linked accounting workflow, and why the review layer deserves to be treated as a product surface rather than an afterthought.

Start with an evidence object, not a journal entry

A common implementation starts with a target object: an invoice, a bank transaction, or a journal entry. A more durable implementation starts with an evidence object that records what the system actually saw.

At minimum, an evidence object should include:

source_type: invoice, bank feed, contract, email, or manual upload
source_id: the provider ID or immutable file reference
observed_at: when the source was retrieved
content_hash: a fingerprint that detects later replacement
extracted_fields: the values read from the source
confidence: a signal for routing, never a substitute for review
raw_location: where an authorized reviewer can inspect the original

The content hash matters more than it first appears. If a vendor replaces a PDF or a connector replays a transaction with changed metadata, the workflow should create a new observation or raise an exception. Silently overwriting the old evidence breaks the chain of reasoning.

Separate observation, proposal, and decision

These are three different events:

Observation: the system found a $12,400 invoice dated March 31.
Proposal: the system suggests office expense, cost center 410, and an accrual period of one month.
Decision: a named reviewer accepts, edits, or rejects that proposal.

Combining them into one mutable record makes the workflow difficult to explain. Keep them as linked records, or at least as append-only revisions with explicit actors and timestamps. A reviewer should be able to see the original extraction beside the final decision, not just the latest state.

This also improves debugging. If a classification rule is wrong, engineers can distinguish a parsing problem from a policy problem. Those require different fixes.

Build the review queue around exceptions

A review queue should not be a dump of everything the system cannot decide. It should answer why a person is being asked to intervene. Useful exception reasons include:

the amount exceeds a policy threshold
the supplier is new or unmatched
the accounting period is closed
the source conflicts with an existing transaction
required evidence is missing
the model suggested a category outside its allowed policy

Each item needs a next action, not just a red badge. For example, “request a purchase order,” “confirm tax treatment,” and “choose an open period” are operationally different tasks. The queue becomes much more valuable when it gives the reviewer the relevant evidence and the smallest decision required.

This is one area where Portali’s evidence-linked workflow approach is useful: the accounting proposal and the material supporting it can stay together while a person handles the exception. The value is not that a human disappears. The value is that the human spends time on judgment instead of hunting through tabs.

Make approval idempotent

Review systems often fail at the handoff. A user clicks Approve, the network pauses, and the browser retries. If approval directly creates a journal entry without an idempotency key, the same decision can post twice.

Use a key derived from the proposal revision and decision action, such as:

approve:{proposal_id}:{proposal_revision}

The posting service should record that key before performing the side effect, or atomically with it when the storage layer supports transactions. A repeated request should return the existing result instead of creating another entry.

Approval should also expire when its inputs change. If the source evidence, amount, period, or account mapping changes after review, create a new proposal revision and require a new decision. Never carry an approval forward just because the record still has an “approved” status.

Measure trust, not just throughput

A dashboard that reports “10,000 transactions automated” can hide a painful process. Add metrics that describe review quality:

percentage approved without edits
percentage reopened after approval
median age of unresolved exceptions
duplicate side effects prevented by idempotency
evidence retrieval failures
time from observation to final decision

The most useful metric may be the percentage of proposals that reviewers can resolve without leaving the workflow. That measures whether the system provides enough context to support an accounting decision.

The practical takeaway

Automation earns trust when it leaves a trail: source evidence, extracted facts, proposed treatment, human decision, and safe execution. The reviewable trail is not paperwork added after the “real” automation. It is the interface that makes automation usable in a controlled finance environment.

Whether you are building an internal close tool or integrating an accounting product, model the evidence and the decision as first-class objects. Start with one exception type, make the provenance visible, add idempotent approval, and measure where people still need to leave the workflow. That is how a fast demo becomes a system a finance team can actually operate.

Your Finance Agent Needs an Evaluation Harness, Not Just a Prompt

Tali Adler — Mon, 21 Sep 2026 11:05:07 +0000

Your Finance Agent Needs an Evaluation Harness, Not Just a Prompt

A finance agent can produce a convincing answer and still be wrong in the one way that matters: it can make a decision without enough evidence.

That is why “add a better system prompt” is not a sufficient quality strategy for accounting automation. Prompts help define behavior, but they do not tell you whether a release reliably classifies transactions, preserves source evidence, routes ambiguity, and refuses to overreach.

The practical answer is an evaluation harness: a small, repeatable test system that runs realistic finance cases through an agent and scores the result against explicit expectations.

Start with the decision, not the model

Before choosing an LLM or tool framework, define what the agent is allowed to decide.

For a transaction-review agent, a useful contract might look like this:

{
  "action": "suggest_category",
  "confidence": 0.91,
  "evidence_ids": ["bank_tx_1842", "receipt_883"],
  "needs_review": false,
  "reason": "Recurring software subscription matches the approved vendor pattern."
}

The important fields are not only action and confidence. An evaluation harness should also check:

Does the suggestion point to evidence that actually exists?
Is the evidence relevant to the transaction?
Does the agent flag missing or contradictory documentation?
Does it stay inside the approved chart-of-accounts scope?
Is the output deterministic enough to audit and compare?

A response that says “software expense” with no evidence may look useful in a demo. In production, it is an unreviewable assertion.

Build a case set with deliberate ambiguity

Do not evaluate only clean examples. Clean examples measure whether the happy path works. They do not measure whether the agent knows when to stop.

A compact starter dataset can contain 50 to 100 cases divided into four groups:

Routine cases: recurring vendors, complete receipts, familiar amounts.
Missing-evidence cases: a bank transaction exists, but the receipt or invoice does not.
Conflicting cases: the vendor name suggests one category while the attached document suggests another.
Adversarial cases: prompt injection inside a memo, unusual currencies, duplicate webhooks, or a transaction that falls outside the agent’s authority.

Store the expected behavior as structured data, not just a paragraph written by a reviewer:

{
  "case_id": "tx_missing_receipt_07",
  "expected_action": "request_evidence",
  "allowed_categories": [],
  "must_cite": [],
  "must_not": ["post_journal_entry", "mark_reconciled"]
}

This makes a regression test possible. If a prompt or model change causes the agent to classify this case anyway, the build should show a failure immediately.

Score behavior in layers

A single “answer quality” score hides too much. Score the workflow in layers instead.

Schema validity checks whether the output can be parsed and whether required fields are present. This catches malformed tool calls and half-finished responses.

Evidence grounding checks that every cited document or transaction exists and supports the claim. You can start with deterministic checks: valid IDs, matching account IDs, date-window constraints, and amount consistency.

Policy compliance checks authority boundaries. A suggestion may be acceptable while an automatic journal entry is not. The evaluator should distinguish “propose,” “request review,” and “execute.”

Decision quality checks the actual accounting outcome against a reviewed label. Keep this separate from writing quality. A beautifully explained wrong category is still wrong.

Operational behavior checks latency, tool-call count, duplicate handling, and retry safety. A model that reaches the correct answer by creating three duplicate reconciliation records is not production-ready.

Test the tools, not only the text

Finance agents rarely operate as chat-only systems. They read transactions, fetch documents, call categorization services, and write review tasks. Your harness should record each tool call as an event:

run_id=eval-2026-09-21-014
case_id=tx_duplicate_webhook_03
step=2 tool=lookup_transaction args_hash=...
step=3 tool=create_review_task result=task_551
step=4 tool=create_review_task result=already_exists
final_action=request_review

That trace lets you test properties that are difficult to see in the final answer:

A repeated event produces one task, not two.
A failed document lookup does not silently become “no document.”
A tool timeout is represented as an exception state.
A write operation has an idempotency key.
The agent does not call a privileged tool when a read-only result is enough.

This is where conventional software testing and LLM evaluation meet. The language model may be probabilistic, but the side effects around it should be bounded and observable.

Run evaluations in CI and in production

Run the curated case set on every prompt, model, tool-schema, and policy change. Keep a versioned baseline so you can compare releases instead of relying on memory.

Then add production sampling. Select a small, privacy-aware sample of completed reviews, redact sensitive values where possible, and send them through the same evaluator. Track failures by category: unsupported claim, missing citation, incorrect escalation, duplicate write, and policy violation.

A useful release gate might require:

100% schema validity
100% policy compliance on adversarial cases
98% evidence-link validity
zero duplicate writes in idempotency tests
no regression in the reviewed decision set

The exact thresholds depend on the workflow. The principle is stable: define the failure that would hurt, then make it measurable.

Keep the human review queue honest

The goal is not to eliminate every review. It is to ensure that the agent sends the right work to review with enough context to resolve it quickly.

A good review item includes the source transaction, proposed action, cited evidence, detected uncertainty, and a clear reason for escalation. Tools such as Portali can fit naturally into this pattern when the accounting workflow needs a shared place for source-linked decisions rather than another opaque automation layer. The product matters less than the design principle: every automated suggestion should remain inspectable.

An evaluation harness turns that principle into an engineering practice. Prompts still matter, models still matter, and good UX still matters. But the durable quality signal comes from repeatable cases, explicit authority boundaries, evidence checks, and side-effect tests.

If your finance agent cannot pass those tests, it does not need a more persuasive demo. It needs a better harness.

The Month-End Close Is a Dependency Graph, Not a Checklist

Tali Adler — Mon, 21 Sep 2026 05:05:03 +0000

The Month-End Close Is a Dependency Graph, Not a Checklist

Month-end close is often managed as a list of tasks: reconcile the bank, post accruals, review accounts receivable, run the trial balance, and sign off. Checklists are useful, but they hide the thing that makes close difficult: most tasks are not independent.

A bank reconciliation can change the cash balance. That change can affect an accrual review, a covenant calculation, or the explanation attached to a management report. An unresolved invoice mismatch can block revenue recognition. A late payroll file can make an otherwise complete close provisional.

The practical improvement is to model close as a dependency graph. Each work item has inputs, evidence, a decision, and downstream consumers. That sounds more technical than a checklist, but it makes the close easier to operate and easier to explain.

Start with a close item contract

For each close item, define a small contract instead of only assigning an owner. A useful contract contains:

Purpose: what accounting question is being answered?
Inputs: which ledger accounts, statements, exports, or schedules are required?
Evidence: which source files or system events support the result?
Decision: what did the reviewer conclude?
Downstream impact: which reports or tasks depend on the result?
Exception rule: what prevents automatic completion?

For example, “reconcile operating bank account” is too vague to be a reliable unit of work. A stronger item says: compare the general-ledger cash balance with the bank statement for the period, link each reconciling item to evidence, classify timing differences separately from errors, and route unexplained differences above a threshold to review.

This structure gives an engineer enough information to build a workflow and gives an accountant enough information to review the result.

Represent dependencies explicitly

A close system does not need a complicated graph database to get started. A relational model can represent dependencies with a few tables:

close_period
  id, entity_id, period_end, status

close_item
  id, period_id, code, owner, state, materiality_threshold

close_evidence
  id, close_item_id, source_type, source_ref, content_hash, captured_at

close_dependency
  upstream_item_id, downstream_item_id, dependency_type

close_decision
  id, close_item_id, reviewer, outcome, rationale, decided_at

The important detail is that evidence and decisions are first-class records. A status such as complete is not enough. Someone reviewing the close later should be able to see what was compared, which source supported it, and why an exception was accepted or cleared.

A dependency should also carry meaning. “Blocks” is different from “informs.” A payroll accrual may block final payroll expense reporting, while a cash forecast update may only inform the management pack. Treating every relationship as a hard block creates unnecessary delays.

Use states that reflect accounting reality

Binary states encourage bad automation. A close item is rarely just open or done. Consider a state machine such as:

not_started -> waiting_for_input -> ready_for_review
ready_for_review -> approved
ready_for_review -> exception
exception -> waiting_for_input
exception -> approved_with_rationale

The approved_with_rationale state matters. It distinguishes a reviewed judgment from an accidentally ignored issue. An immaterial variance might be acceptable, but the system should preserve who made that decision, when they made it, and the rationale they recorded.

Automation can safely move an item from not_started to waiting_for_input when a period opens, or from waiting_for_input to ready_for_review when all required evidence arrives. It should be much more cautious about moving an accounting item to approved.

Make evidence idempotent

Close data often arrives more than once. A bank export may be re-uploaded, an integration may replay an event, or an operator may correct a file and submit it again. If the workflow blindly creates a new evidence record every time, reviewers get duplicate amounts and confusing histories.

Give each source event an idempotency key. Depending on the source, that key could combine the provider name, account, statement period, source document identifier, and content hash. On ingestion:

Calculate the key.
Check whether it already exists.
Store the original event if it does not.
Record a revision if the content changed.
Never silently overwrite the evidence used for an earlier decision.

This is a familiar pattern in payment systems, but it is just as valuable in accounting operations. A close workflow should be repeatable without changing its answer merely because a connector delivered the same event twice.

Turn the dashboard into a review queue

The most useful close dashboard is not the one with the most charts. It is the one that helps a reviewer answer, “What needs my judgment today?”

Prioritize items by blocked dependents, materiality, age, and exception type. Show the source evidence next to the proposed result. Let the reviewer accept, reject, request more information, or approve with rationale. Keep automated matches visible, but do not bury unresolved exceptions beneath a percentage that says the account is “98% reconciled.”

This is also where a tool such as Portali can fit naturally into an accounting workflow: not as another place to copy a checklist, but as a workspace for connecting evidence, proposed accounting work, and explicit review decisions. The implementation details will vary by team, but the principle is stable: the system should preserve the path from source to conclusion.

A practical rollout plan

Start with one high-volume, low-judgment process, such as bank reconciliation or accounts payable matching. Map its inputs and downstream consumers. Add evidence links and explicit exception states before attempting sophisticated automation.

Next, measure three things: time waiting for inputs, time spent investigating exceptions, and the number of post-close adjustments. Those measures tell you whether the workflow is improving the close, rather than simply moving work into a new interface.

Finally, add dependencies one at a time. A good dependency graph is not a reason to prevent progress everywhere. It is a way to show exactly which unresolved question matters, who can answer it, and what becomes trustworthy once it is answered.

Month-end close becomes more predictable when the process reflects how accounting decisions actually work. Checklists tell you what to remember. Dependency-aware workflows tell you what is ready, what is blocked, and why the final numbers can be trusted.

Mortgage Rates Are a Finance-Data Stress Test, Not Just a Headline

Tali Adler — Sun, 20 Sep 2026 11:02:07 +0000

Mortgage Rates Are a Finance-Data Stress Test, Not Just a Headline

A headline about mortgage rates averaging around 7% sounds like a consumer-finance story. For anyone building financial software, it is also a useful systems test. A change in borrowing costs affects forecasts, customer behavior, covenant calculations, cash planning, and the assumptions hidden inside models that were considered ‘stable’ last month.

Recent rate coverage is a reminder that finance teams should not treat economic news as something that lives outside their accounting workflow. The difficult part is not reading the headline. It is turning a changing external fact into a traceable decision without silently rewriting history.

This article presents a practical design for doing that. It is aimed at engineers and finance operators building automation around close, forecasting, and management reporting.

The real problem is not the number

Suppose a finance team sees a report that average mortgage rates are back around 7%. A spreadsheet user might update an assumption cell from 6.75% to 7.00% and move on. That creates several questions:

Which source produced the new value?
Was it an average rate, a quoted rate, or a particular product?
What date and timezone apply?
Which forecasts are allowed to use it?
Which reports already used the old assumption?
Who approved the change?

Without those answers, the number is not really data. It is an untraceable edit. The same problem appears in smaller forms during month-end close: a vendor price change, a revised payment term, or a new bank fee can alter a forecast while leaving no useful explanation for the next reviewer.

Model external news as an event

A robust workflow should represent a news-derived input as an immutable event before it becomes an assumption. A minimal record might look like this:

{
  "event_type": "market_rate_observation",
  "metric": "average_mortgage_rate",
  "value": 0.07,
  "unit": "decimal_rate",
  "observed_on": "2026-09-19",
  "source_url": "https://money.com/current-mortgage-rates/",
  "source_name": "Money",
  "captured_at": "2026-09-20T08:00:00Z",
  "confidence": "reported_average",
  "status": "pending_review"
}

The important fields are not just value and metric. source_url, capture time, interpretation, and review status are what make the event useful later. If the source changes or disappears, the workflow still has a record of what the team actually saw.

Do not overwrite the previous observation. Append a new event and let downstream logic decide whether it is relevant. This makes comparisons possible and prevents a revised assumption from pretending it was always true.

Separate observation, proposal, and decision

One of the safest patterns for financial automation is a three-stage pipeline:

Observation: an external source reports a value.
Proposal: a rule or agent explains which forecast or account may be affected.
Decision: an authorized person accepts, edits, or rejects the proposal.

An agent can be very good at the second stage. It can identify debt-sensitive expenses, compare the new observation with the assumption currently used, and calculate an approximate variance. It should not silently commit a material accounting or planning change merely because the arithmetic is straightforward.

A proposal might say: “The observed rate is 25 basis points above the assumption used in the Q4 interest forecast. Recalculate scenarios A and B. No journal entry is suggested.” That is much safer than a vague alert saying “rates changed.”

Make the calculation reproducible

Every proposal should include the inputs and formula used. For a simple interest estimate:

annual_interest_delta = principal * (new_rate - old_rate)
period_delta = annual_interest_delta * days_in_period / 365

The system should preserve the principal value, both rates, the day-count convention, and the version of the model. A reviewer should be able to reproduce the result without trusting an opaque confidence score.

This is also where idempotency matters. If the same article is ingested twice, it should not create two forecast adjustments. Give each observation a stable fingerprint based on the source, metric, observation date, and normalized value. Duplicate events can be linked to the original rather than processed again.

Design the review queue around exceptions

Most finance teams do not need a person to approve every unchanged metric. They need attention directed toward meaningful exceptions:

the change exceeds a configured basis-point threshold;
the source is new or untrusted;
the affected account is material;
the proposed impact crosses a reporting boundary;
two sources disagree;
the system cannot determine whether the metric applies.

A review queue should show the evidence, proposed impact, affected period, calculation, and available actions in one place. “Approve” should mean approve this specific proposal, not approve future changes forever.

Tools such as Portali are useful in this part of the workflow because the goal is not simply to automate data entry. The goal is to connect source evidence to a proposed finance action and leave a reviewable trail when a human makes the final call.

A practical implementation checklist

If you are adding this capability to an internal finance system, start small:

Define an event schema for external observations.
Store source evidence and capture timestamps.
Keep observations immutable.
Add a proposal layer with explicit formulas.
Use stable fingerprints for deduplication.
Route only material or ambiguous changes to review.
Record the reviewer, decision, and decision time.
Recalculate downstream reports from versioned inputs.
Test late, duplicated, and contradictory source data.

The broader lesson from a mortgage-rate headline is not that every news item belongs in the ledger. It is that finance software needs a disciplined boundary between “the world changed,” “the system estimates an impact,” and “the business accepted a decision.” Keeping those stages separate makes automation faster to investigate, safer to operate, and much easier to explain during the next close.

Don't Let the Agent Post the Journal Entry: Designing Approval Boundaries for Finance AI

Tali Adler — Sun, 20 Sep 2026 05:03:42 +0000

Don't Let the Agent Post the Journal Entry: Designing Approval Boundaries for Finance AI

AI agents are getting good at the parts of finance work that used to require a person to copy values between systems: finding invoices, matching transactions, explaining variances, and drafting reconciliations.

That progress creates an awkward engineering question: where should an agent be allowed to act, and where should it only prepare a decision for a human?

In accounting workflows, the most useful answer is rarely “autonomous” or “manual.” It is a set of explicit approval boundaries backed by evidence, deterministic rules, and an audit trail.

This article walks through a practical design for an agent-assisted close workflow. The examples use invoice and bank-transaction matching, but the same pattern applies to expense review, revenue operations, and fintech support workflows.

Start with a proposal, not a side effect

A dangerous agent tool looks like this:

await ledger.createJournalEntry({
  account: "6100",
  amount: 12840.50,
  memo: "March software expenses"
});

The call is easy to write, but it collapses several different decisions into one irreversible operation:

Which source records support the amount?
Is the period open?
Does the proposed account require approval?
Has another worker already posted an entry?
Who is accountable if the source data is incomplete?

Instead, make the agent produce a typed proposal first:

type JournalProposal = {
  id: string;
  period: string;
  lines: Array<{
    account: string;
    debit: number;
    credit: number;
  }>;
  sourceIds: string[];
  confidence: number;
  exceptions: string[];
  approvalState: "pending" | "approved" | "rejected";
};

The proposal is a durable object. It can be inspected, compared with previous proposals, approved, rejected, or regenerated. Posting is a separate command that accepts only an approved proposal ID.

That separation is more important than the model you use. A better prompt cannot compensate for an API that lets an uncertain suggestion mutate the ledger directly.

Build the evidence bundle before asking for a decision

An agent should not return a confidence score without showing what produced it. For a transaction match, an evidence bundle might contain:

{
  "transaction_id": "bank_8421",
  "candidate_invoice_id": "inv_1092",
  "signals": [
    {"name": "amount_match", "value": true},
    {"name": "vendor_match", "value": true},
    {"name": "date_delta_days", "value": 2},
    {"name": "currency_match", "value": true}
  ],
  "missing": [],
  "source_links": [
    "/bank/transactions/bank_8421",
    "/ap/invoices/inv_1092"
  ]
}

The model can summarize this bundle in plain language, but the application should calculate critical facts itself. Amount equality, period status, duplicate detection, and debit-credit balance are poor candidates for free-form model judgment.

A useful rule is: let the model interpret evidence, but let deterministic code establish the invariants.

This also makes review faster. A reviewer should be able to answer “why is this proposed?” without opening six unrelated tabs or trusting a paragraph generated from hidden context.

Use risk tiers instead of one global confidence threshold

A 98% match confidence does not mean the same thing for every action. Posting a small recurring software invoice is different from changing a revenue account or closing a period.

Define risk using business attributes, not only model output:

function requiredApproval(proposal: JournalProposal, context: Context) {
  if (context.periodClosed) return "blocked";
  if (proposal.exceptions.length > 0) return "senior_review";
  if (context.isRevenueAccount) return "accounting_review";
  if (context.amount > 10000) return "accounting_review";
  if (proposal.confidence >= 0.98) return "auto_approve_eligible";
  return "standard_review";
}

“Auto-approve eligible” still does not have to mean “post immediately.” It can mean the proposal enters a queue where a policy engine, rather than a language model, performs the final check. If your organization is not ready for that, every tier can remain human-approved while the workflow still saves preparation time.

Make tools narrow, typed, and observable

Agent tool design is security design. Prefer several small tools over one privileged “do finance” function:

search_source_records(filters) returns read-only records.
create_reconciliation_proposal(input) stores a proposal.
request_approval(proposalId) changes workflow state.
post_approved_proposal(proposalId, idempotencyKey) performs the side effect.
record_review(proposalId, decision, reason) stores human reasoning.

Every tool call should log the actor, timestamp, input references, output references, and authorization result. Do not log raw credentials or entire documents by default. Store stable IDs and links to the source system instead.

The posting tool also needs idempotency. A worker may time out after the ledger accepts a request, then retry. The idempotency key should be derived from the proposal and posting operation, not generated afresh on every attempt:

const key = `post:${proposal.id}:v${proposal.version}`;
await ledger.postApprovedProposal(proposal.id, { idempotencyKey: key });

Without this, “reliable retry” can become duplicate accounting.

Treat the exception queue as a product surface

The workflow is not successful because an agent produced a high number of matches. It is successful when people can resolve the uncertain remainder quickly and understand why those items were routed to them.

An exception should include:

The proposed action.
The evidence used.
The exact rule or missing data that blocked automation.
Suggested next actions.
A place to record the final decision.

That last piece matters. “Rejected” is less useful than “rejected because the invoice belongs to the prior period.” Review decisions become feedback for rules, reporting, and future agent evaluations.

At Portali, this is the practical distinction between adding an AI chat box to accounting software and building an evidence-linked workflow. The interface can stay simple, but every suggestion should lead back to its source records and its review state. More context is available at portali.tech, but the architectural principle stands independently of any product: keep the decision visible.

Measure the boundary, not just the model

Track metrics that tell you whether the approval design is working:

Proposal acceptance rate by workflow and risk tier.
Percentage of proposals with complete source evidence.
Average time from exception creation to resolution.
Duplicate or reversed postings.
Human edits between proposal and approval.
Reasons for rejection and escalation.

A model benchmark may improve while the accounting workflow gets worse. For example, a more confident model could increase acceptance while hiding a rise in period errors. Operational metrics expose that tradeoff.

A safer definition of autonomy

For finance agents, autonomy should mean fewer repetitive decisions for people, not fewer people in the control loop. The durable pattern is straightforward:

Read source systems through narrow, read-only tools.
Produce an evidence-linked proposal.
Validate invariants with deterministic code.
Route the proposal according to explicit risk policy.
Require approval before consequential side effects.
Post with idempotency and a complete audit trail.
Learn from review outcomes without silently changing policy.

That design lets an agent move quickly without making the ledger mysterious. The best finance automation is not the system that acts most often. It is the system that makes safe action obvious, risky action deliberate, and every decision explainable after the close is over.

The Accounting Feature That Matters Most: Turning Evidence Into a Reviewable Workflow

Tali Adler — Sat, 19 Sep 2026 05:02:10 +0000

The Accounting Feature That Matters Most: Turning Evidence Into a Reviewable Workflow

Most accounting teams do not have a data problem. They have a decision problem.

The invoice is somewhere. The bank transaction exists. A prior-period journal entry is available. The real work is figuring out whether those pieces belong together, what should happen next, and how another person can understand the decision later.

That is why one of the most useful capabilities in a finance platform is not another dashboard. It is an evidence-linked workflow: a way to connect source material, proposed accounting treatment, and human review without turning the close into a black box.

Portali’s source-linked workflow is designed around that problem. The idea is simple: every accounting action should carry enough context to answer three questions:

What evidence led to this proposal?
What decision was made?
What still needs a person’s attention?

Why a normal task list is not enough

A task called “reconcile software expense” tells you almost nothing. It does not say which transactions are included, which contract or invoice was used, whether the amount changed from last month, or why the reviewer approved the treatment.

A task list records activity. An evidence-linked workflow records reasoning.

That distinction becomes important as soon as a close has exceptions. A recurring vendor may suddenly bill for implementation services. A payment may be split across entities. A transaction may look like a duplicate but actually be a renewal. These cases cannot be safely handled by matching text alone.

The workflow should make the normal path fast while making the uncertain path visible.

The capability in practice

Imagine a month-end review for a cloud infrastructure vendor.

A useful workflow can collect the relevant bank transaction, the invoice, the prior-period treatment, and the account history into one review item. It can then propose a classification, show the confidence or matching signals behind that proposal, and leave the reviewer with an explicit choice: approve, edit, reject, or request more evidence.

The important part is not that software made a suggestion. The important part is that the suggestion remains attached to its supporting material and final decision.

A practical review item might contain:

Vendor: Example Cloud Services
Period: August 2026
Amount: $4,820.00
Proposed account: Hosting expense
Evidence: bank transaction, invoice, July posting
Reason: recurring vendor and consistent description
Reviewer action: approved with split between hosting and implementation

This is much more useful than a green “matched” badge. It gives the next reviewer a compact explanation instead of forcing them to reconstruct the investigation from five systems.

Design the happy path and the exception path separately

A common automation mistake is treating every record as if it deserves the same level of friction. It does not.

For predictable recurring items, the workflow can use prior decisions and stable evidence to reduce manual work. For unusual amounts, new vendors, missing documents, or changes in description, it should route the item to a review queue.

That queue is not a failure state. It is where the system protects the ledger from false certainty.

A good exception item should answer:

What made this item unusual?
Which evidence is missing or conflicting?
What is the safest next action?
Who owns the decision?
Can the decision be reused next period?

Capturing the answer matters. If a reviewer explains that a vendor’s annual renewal includes a one-time setup fee, that explanation can become useful context for the next close instead of disappearing into a chat thread.

Make automation reversible

Finance workflows need an audit trail, but they also need operational safety. A proposed classification should not silently become an irreversible posting just because a model was confident.

A safer pattern is:

Gather evidence.
Generate a proposal.
Check policy and exceptions.
Request approval when needed.
Apply the approved action.
Preserve the evidence and decision together.

This structure makes it possible to retry a failed step without duplicating a posting. It also lets a reviewer correct an earlier proposal without losing the original context.

In Portali, the value of the workflow is therefore less about replacing accounting judgment and more about giving judgment a reliable place to happen. The platform can help organize evidence and surface patterns, while the accountable person remains visible in the approval path.

A small implementation checklist

Whether you are building this internally or evaluating a finance tool, start with one narrow workflow, such as recurring vendor expense review.

Check that it can:

Link a proposal to its source documents and transactions.
Show the reason for a match or classification.
Separate automatic approvals from human review.
Record edits, approvals, and rejected proposals.
Preserve an idempotent reference for any downstream posting.
Reuse approved context without hiding new exceptions.
Export a readable explanation for audit or handoff.

If any of these are missing, the system may still save clicks, but it will not necessarily make the close easier to trust.

The real feature is explainability

Accounting teams do not need automation that merely looks finished. They need workflows that make finished work defensible.

That is the promise of an evidence-linked accounting workflow: fewer searches, clearer exceptions, safer automation, and decisions that remain understandable after the person who made them has moved on.

Portali’s approach is a useful reminder that a finance product’s most valuable feature may be the connective tissue between a source, a proposal, and a decision. When that connection is designed well, month-end becomes less about chasing context and more about reviewing the work that actually deserves attention.

You can explore that kind of workflow at portali.tech. The point is not to automate judgment away. It is to give judgment better evidence, better boundaries, and a durable record.