It was a Tuesday in November 2023. We were three days into a month-end close that should have taken five, and our controller — let's call her Priya, because that's her name — was on hour eleven of trying to figure out why our bank feed had silently stopped syncing on the 14th. Two weeks of transactions. Gone. Or rather, not gone — sitting on the bank's side, perfectly visible in the bank's own portal, but invisible to our accounting software because some auth token had expired and nobody had been emailed about it.
The software in question, which I will not name but which everyone reading this can guess, had a "Reconnect" button. Clicking it did nothing. Clicking it again opened a chat widget where a bot asked us to please describe our issue. We described our issue. The bot suggested clearing our cache. We cleared our cache. The bot suggested a Tier 2 agent would email us within 24-48 business hours.
Priya looked at me across the table and said, with the particular calm of someone who has stopped being angry and gone several stages past, "I don't understand why this is still how accounting works."
Neither did I. So we went and built VeloLedger.
What we wanted to fix
This isn't going to be a list of every grievance we have with the incumbent accounting tools. That list is long and most of it is petty. But there are five specific things that we built VeloLedger to fix, and they're the things we'd like you to hold us to.
1. Brittle integrations that fail silently
Every accounting product on the market pitches itself on integrations. "Connects to 800+ apps." "Sync with your bank in real time." What none of them tell you is that those integrations are mostly held together by screen-scraping, undocumented APIs, and OAuth tokens that expire on a rolling basis that nobody at the vendor seems to track.
The result is the experience we had that Tuesday: a bank feed that "works" 96% of the time and that fails the other 4% in a way that is invisible until you go looking. Multiply that across payroll, expense management, payment processors, e-commerce platforms, and inventory — and you have an accounting system that is structurally untrustworthy. You can't actually believe what it tells you, because you can't be sure all the data made it in.
We wanted integrations that announce their own failure, that are deterministic, and that don't depend on us being heroes about our own software. That's why we bet on MCP, but I'll get to that.
2. Month-end that takes a week instead of a day
A clean month-end close for a 40-person SMB should take a day. Two if your AP volume is high. We've seen finance teams routinely take five, seven, sometimes ten days — and almost always the bottleneck is the same: people manually reconciling things the software should have reconciled, manually categorizing transactions the software should have categorized, manually chasing receipts the software should have already matched.
"AI-powered categorization" has been a feature checkbox for a decade. None of it actually works at the level you'd accept from a junior accountant. Which brings me to the next thing.
3. AI bolted on, instead of AI built in
Every legacy accounting tool launched an "AI" feature in 2024. Most of them are a chatbot that can summarize a report you already had, or an autocategorizer trained on a fixed taxonomy that doesn't match your chart of accounts. They're cosmetic.
What we wanted was something different: an accounting platform where AI doesn't sit on top of the ledger but actually reads from and writes to it, with proper guardrails. An AI that can draft a journal entry the way a junior would — and that the controller can review, edit, or reject — and that learns from being corrected. An AI that can run a variance analysis and write the commentary, instead of just generating the table. An AI that can fail gracefully and tell you why.
To do that, you need the AI to have a real interface to your data — not just a SQL pipe into a vector store, but a structured, tool-call-shaped interface that exposes accounts, customers, vendors, journals, and policies as first-class objects. Which, again, is why MCP.
4. Multi-entity treated like an afterthought
If you run more than one company — a holding co with operating subs, a US parent with a Canadian sub, a brand portfolio — you know the experience. Either your accounting software charges you per entity and makes you log in separately for each, or it has "multi-entity" support that consists of running them in parallel with no real consolidation.
We built VeloLedger with multi-entity in the core data model. Entities, business units, departments, classes, and locations are all proper dimensions, not bolt-ons. Intercompany journals net out automatically. Consolidation isn't a separate product — it's a view. Eliminations are tracked, not hand-jammed in Excel and re-keyed every month.
This wasn't a feature we added late. It's the reason the schema looks the way it does.
5. Canada as a second-class citizen
This one is personal. About 70% of the cap-S Serious accounting tools on the market were built in the US and treat Canada as an afterthought. GST and HST handling is hacked together with custom tax codes. PST and QST are barely supported. T4A, T5, T5018 generation is "coming soon" or requires a third-party add-on. The CRA's Business Number structure — with its program account suffixes — doesn't map cleanly to anyone's data model.
If you're a Canadian SMB, or a US company with a Canadian sub, you've spent more hours than you care to count working around these gaps. We've spent those hours too. VeloLedger ships with proper Canadian compliance from day one: per-province sales tax, ITCs tracked at the line level, BN program accounts modeled correctly, and full T4A / T5 / T5018 generation. There's a separate post on what that looks like in detail.
The bet we made
Building a new accounting product in 2026 is, on the surface, an absurd thing to do. The category is mature. The incumbents are entrenched. CFOs and controllers do not, generally speaking, wake up wanting to migrate ledgers.
But there's a structural shift happening underneath all of this, and we're betting on it.
MCP as the foundation, not a sidecar
The Model Context Protocol is, in essence, a way for AI models to talk to systems with the same kind of structured tool calls that an engineer would use against an API. It is, to put it bluntly, the thing that makes "AI-native" software possible instead of just being a marketing claim.
VeloLedger is built MCP-first. Every meaningful operation in the ledger — read a balance, draft a journal entry, post one, generate a 1099 or T4A, run a variance — is exposed as an MCP tool. That means an AI agent (ours, or yours, or your auditor's) can do those things with the same guardrails a human would have. Permissions, audit trails, approval workflows: all enforced server-side. The AI cannot do anything a human couldn't do, and everything it does is logged the same way a human's action would be.
This is unglamorous infrastructure work. It is also the difference between AI that occasionally hallucinates a credit and AI that you can actually trust in your books.
Sibling products as first-class data sources
VeloLedger does not exist in isolation. It's part of a family — VeloPulse (HRIS/payroll), Velo Expense Management, Velo CRM — and each of those products is wired to VeloLedger via MCP, not via brittle webhooks or nightly CSV exports.
What that means in practice: when a contractor invoice is approved in Expense Management, the journal entry lands in the GL in seconds, with the right account, dimension, and tax code, and the source document attached. When payroll runs in VeloPulse, the burden allocation hits the right departments. When a deal closes in Velo CRM, the deferred revenue schedule is drafted automatically.
You can use VeloLedger without the rest of the family. But if you use them together, you stop having "integration problems" because the integrations aren't integrations — they're shared infrastructure.
Built for an era where AI does the boring parts
We don't think AI is going to replace controllers. We think AI is going to replace the parts of a controller's job that nobody enjoys — the categorization, the chasing, the re-keying, the variance commentary that says "expenses up $14K, driven by software subscriptions" for the seventeenth month in a row.
What gets left behind is the judgment work: the close memo, the unusual transaction, the audit conversation, the decision about a reserve, the explanation to the CEO about why the gross margin moved. That's what accountants are good at. That's what they should be doing. VeloLedger is built to take the rest off their plate.
What's next — and what's not there yet
We want to be honest about the state of the product. Here's what we have today, and what's still coming.
What works today: Full general ledger, AP, AR, bank feeds with proper failure handling, multi-entity consolidation, Canadian and US tax compliance, MCP integration with VeloPulse and Velo Expense Management, AI-drafted journal entries, AI-generated close memos, T4A/T5/T5018/1099 generation, audit trails, role-based permissions.
What's coming in 2026: Inventory and COGS module (Q3), fixed asset register with built-in depreciation schedules (Q3), expanded SOX-ready controls package (Q4), Velo CRM MCP integration (Q4), expanded e-commerce platform connectors (rolling).
What we're not building, on purpose: A 200-app marketplace of mediocre integrations. A "drag-and-drop dashboard builder." A custom report writer that requires three days of training. A separate "consolidation product" that costs extra.
If any of that disqualifies us for you, that's fair. If it sounds like a relief, that's the audience we're building for.
One last thing. If you've read this far, you probably have your own Priya-on-hour-eleven story. We'd genuinely like to hear it — not because we're going to sell you something, but because the things that frustrate you about accounting software are the things we want to keep fixing. Email us. Or just book a 15-minute conversation. No deck.
— The VeloLedger team