Cosmin Nicolaescu - Accrual
The Engineer Who Never Stopped Building
Cosmin Nicolaescu is mid-conversation when he mentions it almost as an aside: while we’re talking, code is being written in the background. By tools he has set in motion, iterating on a product already inside some of the largest accounting firms in the United States. He will check in between meetings, course correct, and keep it moving. This is how he works.
That detail is the clearest window into how Cos built Accrual, and why the company looks the way it does.
Meet Cos, and Meet Accrual
Cos spent years as CTO at Brex, one of the most technically demanding fintech companies of its generation. He sat on the board, participated in every fundraising round, and scouted for Sequoia. He had a front-row seat to what great financial infrastructure looks like, and what happens when it breaks. When he left Brex to explore his next move, he spent time reading, traveling, and, by his own account, writing more code than he read books.
“Writing code is one of the most satisfactory things in my life. Almost every day, if I had a choice, I would end up writing code.”
That instinct pointed him toward the problem he founded Accrual to solve.
Accrual builds software for accounting firms, specifically the top 50 to 100 firms in the United States by revenue. The product helps accountants process tax returns faster and with far greater accuracy, sitting on top of existing tax engines and rebuilding the workflows around them from the ground up. This past tax season, the platform processed roughly 15,000 returns, ingested approximately 1.5 million pages of documents, and generated 99.7% of all worksheet fields using AI. Across that entire volume, fewer than 1,000 fields required a human correction.
Cos built this alongside co-founder Siddarth Chandrasekaran, known as Sidd, also a deeply technical engineer and the person who manages the majority of the builder-side work at Accrual day today.
A Neglected Market, by Design
Accounting attracted very little venture attention before the current AI era. Cos is direct about why.
“If you look at some of the modern solutions, things built over the last 10 years in the accounting space, none of them are really Silicon Valley startups. The caliber is different. The investors are different.”
The sector was considered unsexy, lumped in with legal and other professional services that generalist investors tended to pass over.
That neglect left accountants with tools built in the nineties, a constellation of three to seven disconnected point solutions that firms stitched together manually, importing and exporting between systems and losing efficiency at every handoff. The tools were not good, and the firms knew it.
“The amount of over-promise and under-delivery in this space was much higher than in other industries,” Cos said. “Over and over again, I would talk to firm owners who would tell me: we tried this tool, trained people, deployed it, spent weeks on it, and then it ended up being a disaster.”
That history of failed deployments explains why accountants often appear conservative from the outside. They have been burned by change, repeatedly, and have learned to protect their practices accordingly.
Accrual’s decision to focus on accounting firms, rather than in-house accounting teams at businesses, came down to breadth of impact. The majority of small and mid-sized businesses in the United States rely on outside accounting firms entirely. If the goal is to improve financial outcomes at scale, the firms are the lever. Internal teams at large enterprises represent a narrower slice of the work.
Cos chose to target the largest firms first, a deliberate inversion of the typical startup playbook. His reasoning rests on a principle he stated plainly: change management is harder than technology. That holds whether you are deploying software at a $5 million firm or a $100 million firm. The complexity of training staff, navigating tax seasons, and earning practitioner trust does not scale down proportionally with firm size. Given that, he reasoned, you might as well capture the complexity premium by going upmarket from the start.
There is also a structural risk that shaped the decision. Smaller accounting firms are being acquired at a rapid pace by private equity-backed roll-ups, and when a firm gets absorbed, the acquirer’s technology typically displaces whatever the acquired firm was using.
“You run the risk of going and deploying your software with these smaller firms, and then a larger firm ends up acquiring them and then displacing you because they’re like, well, whatever the acquirer uses is what’s going to be the end solution. You end up potentially spending two years on the wrong thing in a market that has high M&A activity.”
The product direction follows the same logic. Accrual started with the most complex client profiles: ultra-high-net-worth individuals, family offices, multi-entity returns, and worked outward from there. Simpler cases are a subset of that complexity, and the journey is much harder to make in reverse.
“If you start at the bottom and try to move your way up in terms of complexity, it’s really hard to prove your way versus the other way around.”
The Engineer Who Stayed
Most technical founders reach a point where the company grows large enough that management, fundraising, and strategy consume the calendar. The code stops. Cos describes that transition at Brex plainly. He needed to make it, and he understood why it was the right call. He also found it deeply frustrating.
“It’s been the most frustrating thing moving into more senior roles. At Brex, I spent the first few months mostly writing code because I wanted to learn the codebase. And then beyond that, I spent almost no time writing code just because that was not the job and not what I needed to be.”
When he reflects on how he structured Accrual, the answer keeps coming back to not wanting to recreate that condition. Today he writes code daily, though he is careful about what that means in practice. He avoids putting himself on the critical path for anything major, knowing his pace will always be slower than a focused engineer given his other responsibilities. Instead, he gravitates toward the bottom of the priority stack, features that a dedicated engineer could finish in a day or two, where a week-long timeline on his end creates no real drag. He also uses builder time to prototype new product directions and develop intuition on ideas before bringing them to the team.
Sidd, by contrast, spends roughly 95% of his time on the builder side, overseeing not just what gets built but how the architecture evolves over time.
The AI tooling has changed the practical trade-off in ways Cos finds meaningful. “Before, I would spend the next three hours on one problem. Now I can spend those three hours on five things at once.” He puts the practical ceiling at two to four concurrent workstreams before output quality starts to degrade. Beyond that, he said, “it probably ends up becoming slop if you don’t pay enough attention.”
He has also developed a pointed opinion about the “I had to stop coding” narrative common among senior engineering leaders, one he offers as a personal observation rather than a researched claim. In his experience, founders and executives who genuinely love writing code return to it the moment they have unstructured time, between jobs, on weekends, wherever they can find it.
“My spicy thought is that most folks who move up the management chain don’t actually enjoy building code as much as they enjoy management. It’s very few engineering leaders who use time between jobs to just write code, despite the fact that they hadn’t done it in their job.”
The harder adjustment, he said, has been learning to work with people who operate at a different analytical pace. Early on, when a prospect would go quiet after a pilot, his instinct was to diagnose it as a product failure. More often, it was simply the rhythm of their world. “Assume good intent and don’t read into it until someone explicitly tells you something” is now a principle he tries to hold onto.
Cap Table as Culture
Cos came into fundraising with context most first-time founders do not have. He had been present for Brex’s rounds, participated in board meetings as a CTO, and spent his gap year in deliberate conversations with investors at top funds, not to pitch, but to understand how they think. That background informs a framework for investor selection that is more deliberate than the standard advice.
His first principle is quality over quantity. A small check from an investor who is not genuinely bought in creates more downside than most founders account for. That investor might pass on the next round, fund a competitor, or simply not return calls when the situation gets complicated.
“If investors are not really bought in, they don’t really care that much. They won’t necessarily hurt you, but they might not spend that much time with you either.”
His second filter for investor selection: whether he actually wants to spend time with the person.
“I’ve seen founders where they hate the idea of meeting with this investor. They’re a pain in the ass. And I tell them, why did you let them on your cap table? It wasn’t even that they had no choice. They just didn’t think through that angle.”
His third consideration is time horizon clarity. A seed-stage investor who is excellent at the earliest stages but adds little value by Series B is a known limitation, and that needs to be understood before the check clears. Discovering it years later is a different problem entirely.
“I’ve seen investors go with seed funds and feel very good about it, and then several years later they’re like, that seed fund investor is not helping me at all, but they still own 10% of my company. I’m like, yeah, but that was very obvious in hindsight.”
Cos is candid that his network access is not typical. The ability to be selective with investors is partly a function of having the right early traction and the right relationships coming in. Still, the underlying principle applies more broadly: founders tend to have more agency over their cap table than they exercise, and the cost of ignoring that surfaces years down the road.
When the Product Proved Itself
Cos describes two inflection points that mattered most. The first was technical: proving that Accrual’s integration with existing tax engines could actually work, that accountants could experience their workflows as something fundamentally different rather than incrementally improved. That came together in the summer before their first live traffic, then got real confirmation during extension season.
The second was harder to engineer: unsolicited feedback from end clients. High-net-worth individuals who had no direct relationship with Accrual, some of whom Cos had never met, reached out to say their experience working with their accounting firm had noticeably improved.
“Until you actually have that sort of live traffic, it’s really hard to get confirmation that the bets you’ve made will pay off. Getting that confirmation was extremely rewarding.”
That confirmation points toward what Accrual is ultimately building toward. Cos’s thesis is that the tools available to accounting firms have historically driven one outcome: efficiency. Getting the books closed faster, reducing hours per return, cutting outsourcing costs. Those gains matter, but they do not grow a firm.
“Our thesis was always that while we’re optimizing for the accountants, there’s an end client that they’re serving whose primary optimization is time.”
If the client experience improves meaningfully, firms using Accrual should see higher growth, not just higher efficiency. That is the differentiation Cos believes the industry has been missing. The accounting software market has spent decades solving for the accountant. Accrual is betting that solving for the client changes the economics of the whole firm.
More from Uncovered Media
 | A guest post by
|
 | A guest post by
|