Does any of this post directly to my general ledger?

No. Proposed entries are held for a CPA to review, and nothing reaches your production ledger without a human approving it. Writes back to QuickBooks or Xero are explicit and logged. That's the whole point of the arrangement.

What tools do you use under the hood?

Claude and OpenAI models for the reasoning, embeddings for matching against your chart of accounts, Postgres for the data we hold, and Inngest to schedule the runs. We pick the model per task rather than locking the firm to one vendor.

How does this differ from off-the-shelf accounting AI?

Off-the-shelf bots are trained on a generic ledger and a generic chart of accounts. What we build is tuned against your CRM, your processes, and your chart, and on a new chart the first few weeks run at a lower confidence threshold on purpose. The CPA review catches what tuning misses.

PC Financials owns and maintains the code it writes. You get the outputs, the audit trail, and written documentation, not the source. That's how we keep the engagement portable across clients without leaking one firm's tuning into another's.

AI & Automation · PC Financials

Running on the desk

qbo a/r app · the fast working surface over QuickBooks A/R: find it, fix it, print it, collect it · human-approved write-back ▸ discovery · inside your processes and systems, old and new, finding what's actually broken · week one ▸ implementation · fixes, integrations, and AI where it earns its place, until the pieces talk to each other · weeks two to three ▸ run · the data, the reporting, the books, and tax, run on what we built · ongoing ▸ stack · TypeScript · Python · Postgres · Supabase · Cloudflare · Inngest · Claude · OpenAI ▸ qbo a/r app · the fast working surface over QuickBooks A/R: find it, fix it, print it, collect it · human-approved write-back ▸ discovery · inside your processes and systems, old and new, finding what's actually broken · week one ▸ implementation · fixes, integrations, and AI where it earns its place, until the pieces talk to each other · weeks two to three ▸ run · the data, the reporting, the books, and tax, run on what we built · ongoing ▸ stack · TypeScript · Python · Postgres · Supabase · Cloudflare · Inngest · Claude · OpenAI ▸

§ 1

Intelligence

AI & Automation.

The same numbers get keyed into three systems. The close eats a week. Somebody rebuilds the same report by hand every month, and the automation you already bought never quite worked.

The rote work runs on a schedule instead of on a person, tuned to your chart of accounts and your actual processes, with a CPA reviewing the edge cases before anything reaches the ledger.

What you get

· Discovery across your processes, your systems, and the automation that never worked
· AI and automation built against your CRM, your processes, and your chart of accounts
· The workflows between the CRM, the systems, and the books, running unattended
· A CPA review step on every edge case, and a written record of what changed

How this engagement runs

The shape of the system

Each build gets a scope, a schedule, and a written runbook. Nothing ships work directly to the books: proposed entries go to a staging table that a CPA reviews on a fixed cadence. The automation’s job is to do the rote work so the human can spend their time on the part that requires judgement. The arrangement matters: if the automation is ever in a position where its output goes straight to a production ledger without a CPA seeing it, the firm has lost the thing that makes the engagement worth paying for.

What gets built is decided in discovery, not picked from a catalog. The work usually lands in a few recurring shapes: transaction categorization tuned to your chart of accounts, reconciliation across bank, processor, and ledger, cash forecasting, variance and anomaly flagging, and the workflow automation between the CRM and the books. Which of those your engagement actually needs, and in what order, comes out of what discovery finds broken.

Tuned to your chart, not a generic model

Categorization accuracy is one of the things every automation vendor claims and nobody benchmarks honestly. The honest version is conditional: the automation gets reliable once it has seen a chart of accounts for a while and has enough operating history to learn its patterns. So we don’t publish an accuracy number. Every disagreement between the automation and the CPA goes back into the tuning, and the engagement is designed so a wrong answer costs a review click rather than a wrong ledger.

The misses aren’t random. They cluster around three patterns: ambiguous vendor names where the memo could plausibly be one of two accounts (a Stripe payout that could be sales or a refund reversal), transactions where the right answer depends on context only the operator has (a wire labeled “consulting fees” that’s actually a refund), and new vendors with no prior history. The first two require a CPA. The third resolves itself within a billing cycle.

When we onboard a new chart, the first weeks run at a lower confidence threshold. The agent flags more transactions for review, learns the chart, and the review queue contracts week over week until it settles.

CPA-in-the-loop, not as marketing

Every agent the firm runs has a human review step. This isn’t a regulatory hedge or a marketing posture; it’s the operating model. The reason is direct: the financial statements are an attestation about a business. The CPA is the person attesting. If the attestation is wrong, that’s a problem for the CPA, not the model. So the CPA reviews the edge cases, signs off on the close, and owns the answer.

What this means in practice: the agents save the work that’s expensive in person-hours and cheap in judgement (the categorization, the matching, the variance flagging) and leave the work that’s cheap in person-hours and expensive in judgement to the CPA. The work that used to consume a senior accountant’s days happens overnight, and the CPA spends the recovered time on the edge cases the agents flag, plus the work that wasn’t getting done because the close consumed the calendar.

Standalone, or the engine for the whole operation

This line is sellable on its own. If you already have a finance team and the pain is manual work that shouldn’t be manual, we’ll implement AI and automation against their existing workflows, no requirement to hand us the books. It’s also the engine when we run the full operation: the same agents are what let one firm keep a clean close across §3–§6 without a back office full of people.

What we don’t do is ship the agents as standalone software. They stay proprietary to the firm (implemented, tuned, and maintained as part of the engagement, not licensed as a product). Selling them as software would change the model into something neither side wants.

What the operator sees

Output, not machinery. The reporting that comes out of §4, on the cadence that section sets, and a written record of what the automation proposed and what the CPA did with it. If a build stops earning its place, we say so at the quarterly review and retire it.

What the operator doesn’t see: the prompts, the tuning, the schemas, the failure-handling code. That’s the firm’s problem, not the operator’s, and the engagement is set up so the operator never has to learn any of it to get the benefit.

Frequently asked

Does any of this post directly to my general ledger?: No. Proposed entries are held for a CPA to review, and nothing reaches your production ledger without a human approving it. Writes back to QuickBooks or Xero are explicit and logged. That's the whole point of the arrangement.
What tools do you use under the hood?: Claude and OpenAI models for the reasoning, embeddings for matching against your chart of accounts, Postgres for the data we hold, and Inngest to schedule the runs. We pick the model per task rather than locking the firm to one vendor.
How does this differ from off-the-shelf accounting AI?: Off-the-shelf bots are trained on a generic ledger and a generic chart of accounts. What we build is tuned against your CRM, your processes, and your chart, and on a new chart the first few weeks run at a lower confidence threshold on purpose. The CPA review catches what tuning misses.
Who owns the code?: PC Financials owns and maintains the code it writes. You get the outputs, the audit trail, and written documentation, not the source. That's how we keep the engagement portable across clients without leaking one firm's tuning into another's.