Ankor
Order-to-cash reconciliation and revenue recognition for commerce. Lessons from building a team, raising capital, and learning what actually matters.
"There's only two ways to make money in business: bundling and unbundling." — Jim Barksdale, 1995
At Juni, I watched e-commerce brands fail to get credit—not because they weren't profitable, but because they couldn't prove it. Cash flow was real. Data was scattered across Stripe, Shopify, Klarna, and a spreadsheet someone built two years ago and was now afraid to touch.
The pain wasn't analytical. It was operational. Finance operators knew exactly what needed doing. They just couldn't do it. Month-end meant downloading payouts, cross-referencing orders, hunting mismatches. The work was known. The tooling didn't exist.
The Wrong First Version
We built what fintech usually builds: visibility. Dashboards. Better views of data.
Users looked at it, nodded, and went back to their spreadsheets.
They didn't want to see the reconciliation. They wanted it done. The job wasn't "help me understand my data." It was "make this task not exist anymore."
Accelerators, Not Flexibility
The rebuild: a connector layer between commerce systems (Shopify, Centra) and accounting systems (QuickBooks, Xero). Normalize the data—every payment provider describes transactions differently—then feed it into Accelerators.
Accelerators are narrow, workflow-specific agents. Not a rules engine users configure. Not a flexible reconciliation tool. Hardcoded, auditable, deterministic. Does one thing: Payment Reconciliation, or 3-Way Match, or Payout Traceability.
The key decision was not building flexibility. Enterprise tools like Duco let you configure anything. Wrong abstraction for a 3-person finance team. They don't want to build logic. They want outcomes.
The Aggregator Trap
Do you build integrations yourself or rely on aggregators?
Codat and Merge promise a single API to dozens of accounting systems. Compelling pitch—why maintain 15 integrations when someone else will?
What the pitch doesn't mention: aggregators optimize for breadth, not depth. They give you data common across all systems, which means losing data specific to any one system. For reconciliation, specific data is the whole point. The field Xero calls one thing and QuickBooks calls another—that's where bugs live.
We tried aggregators first. Hit edge cases they couldn't handle. Built critical integrations ourselves. Ended up maintaining both—aggregator for long tail, custom for systems that mattered.
Aggregators are a shortcut to breadth but create a ceiling on depth. At some point you decide which systems are strategic and own those end-to-end. The middle ground—half aggregator, half custom—is worst of both worlds.
The Upmarket Trap
We started with SMBs. $5M–$50M revenue band where complexity has outpaced capacity but the business can't afford enterprise tooling. Systematically underserved.
Then we tried to go upmarket.
SMB sales: demo-to-close in weeks. Mid-market: demo-to-pilot-to-security-review-to-procurement-to-close in months. Same product, same pitch, entirely different process.
Our product could handle the technical requirements. Our company couldn't handle the sales cycle. Cash burn doesn't wait for procurement timelines. A 6-month enterprise deal is great with 18 months runway. Fatal with 9.
Going upmarket isn't about having a better product. It's about having enough capital to survive the sales cycle. Product requirements are actually easier—enterprises know what they want and will tell you. The constraint is time.
Knowledge Silos
Building a team from scratch means building everything from scratch. Not just product—culture, processes, ways of working that established companies take for granted.
First hire is terrifying: asking someone to bet their career on your idea. Fifth hire is terrifying: people's livelihoods now depend on decisions you're making with incomplete information.
What I underestimated: silos form immediately. Three people, and there's already information living in one head and nowhere else. Ten people, and whole subsystems only one person understands.
Team transitions make it worse. Someone leaves, takes context never written down because it seemed obvious. The person who knew why billing works that way is gone. Now you're reverse-engineering decisions from code comments and Slack threads.
The documentation you'll write later never gets written. The processes you'll formalize when you have time never get formalized. Knowledge transfer happens in hallway conversations you don't have when everyone's remote.
Taste vs. Shipping
Hardest management problem: engineers who wanted to rebuild things that worked.
Often the existing code was genuinely bad. Built fast, with shortcuts, by people learning the domain while building. Any engineer with taste would want to refactor.
But refactoring doesn't ship features. Rebuilding auth doesn't close deals. The codebase making engineers cringe is running in production, serving customers, generating revenue.
The negotiation is constant: when does technical debt matter enough to pay down, versus when is it preference disguised as necessity? I got this wrong in both directions—shipping on systems about to collapse, approving rewrites that delivered no business value.
The codebase is never going to be good. Early-stage code is written under pressure, with incomplete information, by a team smaller than the problem requires. The goal isn't clean code. It's code that ships and doesn't break.
The Pitch Deck Lies
Not intentionally—you can't fit full complexity into 12 slides. So you simplify. Tell the investable story. Leave out parts that are true but complicated.
Then you raise against that simplified story, and now you build the simplified version instead of the real one. The funded version is different from the version you know needs to exist.
Best investors understand this. They pattern-match on founders, not slides. But the process still selects for stories that fit the format—clear problem, solution, market, path to returns. Messy truth: you're figuring it out as you go, market is a guess, path to returns depends on things you can't control.
What I wish I'd known: terms matter more than valuation. Board composition matters more than check size. Small details during negotiation become constraints you live with for years.
Every Payout Tells Two Stories
One about cash, one about revenue. They happen on different days.
A customer needed this. Real customer, complex use case where "record it when it lands" would've been technically wrong and practically useless.
The complexity: each line item in a payout could represent a different product, different billing period, different revenue recognition rules. A single payout wasn't a transaction—it was a bundle of obligations, each maturing on its own schedule.
I expected the hard part to be accounting logic. Debits, credits, clearing accounts, period mapping. That's not what mattered.
What mattered: knowing what you don't know yet—until you run real data through it.
Revenue recognition's counterintuitive thing isn't the concept. It's the cardinality explosion at the line-item level. You think you're building one rule. You discover you're building N rules, where N is distinct product-period combinations in a single payout. You don't know what N looks like until real customer data tells you.
Two Details That Are The Point
Individual posting dates per line item. The alternative—one date per payout—collapses schedule into a point. You've thrown away information that makes revenue auditable. Each line item needs its own date because each is a separate recognition event. They just arrived together.
Pro-rata allocation by day count. Equal period slices are wrong the moment billing straddles months of unequal length. Day-count proration stays accurate regardless of calendar position. It's what auditors accept without question—defensible from first principles.
Both prevent the same failure: someone asks "where did this number come from" and the system can't answer.
In fintech, explainability isn't transparency for its own sake. A number without a path back to source isn't a financial figure—it's an assertion. Drilldowns alone aren't enough. The real unlock is context with relevant action—showing someone why a number is what it is, then giving them something to do about it.
What I Believe Now
The product is the easy part. Code is the easy part. Hard part is everything else—team, capital, sales cycle, market timing, decisions made with incomplete information that can't be undone.
Complex processes only reveal themselves through real data. Prototyping isn't a phase—it's the discovery method. Skip it and you build the system you imagined, not the one actually needed.
Early stage is survival, not optimization. Right decision is the one keeping you alive long enough to make the next decision. Metrics that matter aren't in your investor update—they're runway, burn rate, and gap between what you promised and what you've shipped.
Barksdale was right: bundling and unbundling are the only moves. We were unbundling reconciliation from the ERP, making it standalone. Question was always whether we'd stay unbundled or get rebundled into something larger. That's the exit either way—bought by the bundle, or become the bundle yourself.
Ankor was the hands. The lesson was that hands need a body.
