Why the Shiny New Ledger Breaks the Moment You Need a Bonded WIP Schedule

In the last article I gave the AI-native accounting tools a fair hearing, because they earn it, for the businesses they were built for. This article is about what happens when your business is a contractor who runs jobs, carries work-in-progress, and needs a bank or surety to trust your financials. Here the picture changes sharply, and for reasons that are worth understanding precisely, because they’re not the reasons most people assume.

Let’s take the honest concern in three layers, from the obvious to the one that actually decides it.

Layer one: some of these tools can’t close accrual books

Start with the most basic problem. A bonded contractor lives or dies on accrual-basis financial statements: statements that recognize revenue as you earn it and match costs to the jobs that generated them, not just when cash moves. Your surety’s entire analysis assumes accrual books with a proper work-in-progress schedule.

Some of the new tools simply aren’t built for that. Kick, for all its convenience, is a cash-basis bookkeeping layer: it categorizes and reconciles, but full accrual accounting, formal period-end close, and journal entries aren’t what it’s for. A contractor keeping books in a cash-basis tool has, from a bonding standpoint, no usable financial statements at all. That’s not a knock on the tool. It’s just built for a different job. But it’s a hard stop for construction.

That eliminates the bookkeeping-layer tools right away. The ERPs (Rillet, Campfire) can do accrual, close, and consolidation beautifully. So they clear this bar. Which brings us to the real problem.

Layer two: none of them do construction’s specialized accounting

Even the powerful ERPs were built for a specific kind of company, and construction isn’t it.

Rillet’s revenue-recognition engine is designed around subscription contracts synced from a sales CRM, applying the ASC 606 standard to recurring software revenue. That’s genuinely sophisticated, and completely different from construction revenue, which runs on percentage-of-completion: recognizing revenue as a job progresses, based on costs incurred against estimated total costs, with all the over- and under-billing calculations that produce a WIP schedule. That’s not a setting you toggle on in a SaaS-oriented ERP; it’s a different accounting model entirely.

Then there’s certified payroll for prevailing-wage work, committed-cost tracking, retainage, AIA progress billing, and job-cost structures with cost codes and phases. None of the AI-native tools were built with any of that in mind, because none of them were built for contractors. They were built for software companies.

So already you’d set them aside for construction. But suppose you were willing to handle the construction-specific accounting elsewhere and just use one of these ERPs as a clean, automated general ledger underneath. That’s a reasonable thought, and it runs straight into the third layer, which is the one that actually settles it.

Layer three: the data can’t get in

Remember the two-layer model from the first article: your operational system (JobTread, ServiceTitan, Buildertrend) runs the jobs, and the ledger is the record. The entire value of an AI-native ledger comes from data flowing into it automatically and continuously. That’s the whole trick: the “zero-day close” only works because the tool is wired directly into the systems where your transactions originate.

So the deciding question is brutally simple: can your construction operational system feed one of these ledgers?

I checked this directly, because it’s the fact that decides everything. Here’s what’s true as of this writing:

JobTread’s own best-in-class accounting integration is with QuickBooks Online: a mature, two-way sync of invoices, bills, payments, customers, vendors, and cost codes. That’s the connection it’s built and supports. There is no native connector from JobTread to Rillet, Campfire, or Digits. Same story for ServiceTitan and Buildertrend: their supported accounting paths run to QuickBooks, Xero, and established construction ERPs, not to the AI-native newcomers.

And from the other side, the AI-native ledgers publish their featured integrations openly, and they’re all the same SaaS finance stack: Salesforce, HubSpot, Stripe, Ramp, Brex, Rippling, Gusto, bank feeds. No construction operational systems appear anywhere on those lists. When one of these ledgers announced a major new data partnership in early 2026, its flagship partners were corporate-card platforms: the software-company ecosystem, not the jobsite one. These platforms are building away from construction, not toward it.

That means the only way to get your job-cost data from JobTread into a Rillet or Campfire would be a generic middleware bridge, a spreadsheet import, or a custom-built connector. And here’s why that’s disqualifying for a bonded contractor specifically: the automation was the entire reason to choose the tool, and the automation is exactly the part that doesn’t exist for construction. Strip it out and you’ve got an expensive ERP that you’re feeding by hand, which is slower and riskier than the proven path, not faster.

Why this matters extra for attest work

There’s a further wrinkle if you need reviewed or audited financials, or a WIP schedule your surety’s CPA will scrutinize. A homemade data bridge sitting between your job software and your ledger isn’t just inconvenient. It’s an unproven link in the chain that produces your financial statements. When a reviewer or underwriter has to trust your numbers, “we built a custom connector” is a liability, not a feature. The proven JobTread-to-QuickBooks path, by contrast, is so well-worn that there’s an entire cottage industry of specialists who do nothing but set it up correctly. That maturity is itself an asset when someone is deciding whether to trust your books.

This isn’t “new bad, old good”

It would be easy to read this as an old-school CPA waving off new technology. It isn’t. The AI-native tools are genuinely excellent, and for the right business I’d recommend one without hesitation. If you run a software company, a professional-services firm, or any business whose operations already live in the Stripe-and-HubSpot world, these ledgers can give you a continuously-closed, audit-ready set of books that a traditional monthly cycle can’t match.

Construction is simply on the wrong side of the line, today. The specialized accounting isn’t there, and more decisively, the data pipeline from your job software isn’t there. The single thing that would change this is a native connector from JobTread or ServiceTitan into one of these ledgers. If that ships, the conversation reopens overnight. Until then, the responsible ledger for a bonded contractor is the one the data can actually reach.

The bottom line

For a bonded contractor, the shiny new ledger breaks at three points: the simplest tools can’t even close accrual books; the powerful ones don’t handle percentage-of-completion, certified payroll, or the rest of construction’s specialized accounting; and (the decider) your job-management software has no supported way to feed them, so the automation that justified the whole purchase doesn’t exist for you. None of that makes these bad tools. It makes them the wrong tools for this job, right now.

In the final article, we’ll turn all of this into a clear prescription: the right operational-plus-ledger stack by contractor type, so you know exactly what to run.

If you’re staring at this decision for your own business, book a discovery call and we’ll work out the right stack for where you actually are. No software to sell.