Accounting built for how your platform actually moves money.
Built for founders who speak both languages and need an advisor who does too. Kellcat designs the accounting architecture before your first transaction, then keeps the books, dashboards and Cash Map current as you grow.
Your Stripe deposits aren’t your revenue.
The Stripe Connect & Clean Books Guide: 24 pages on charge types, money held for sellers, refunds, disputes and a month-end that ties out to the penny.
Platforms Kellcat works with
Puzzle
n8n
zapier
You can explain your system architecture. Can your accountant follow along?
Most accountants cannot. Your CPA understands revenue recognition in theory. Your engineering team can build anything. But neither of them has designed a journal entry framework for a Stripe Connect billing agent model, mapped a deferred revenue schedule to a usage-based billing engine, or told your dev team exactly what data to push to Puzzle and when.
Kellcat sits in that gap. With eleven years of software engineering and a second-generation accounting background rooted in a CPA firm, Kellcat speaks both languages. Kellcat designs the accounting infrastructure your technical team builds to and sets it up in Puzzle so it works from the first transaction.
Most bookkeepers learn your accounting after your business is built. Kellcat designs your accounting architecture before your first line of code is written.
Your CPA
Knows the rules. Sees the books at year-end, after the platform is built.
Your engineers
Build the money flows. Don't decide how each event should hit the ledger.
Where Kellcat works
Turns your payment events into accounting rules, writes the spec your engineers build to, and flags what needs your CPA's opinion before go-live.
This page is for you if…
If any of these sound familiar, your accounting infrastructure needs to be designed, not defaulted.
- You think in systems, not spreadsheetsYou'd rather talk webhook event triggers than basic bookkeeping, and you need an accountant who gets that.
- Money moves through your platform on behalf of othersProviders, sellers, contractors or partners, and that pass-through needs to be accounted for correctly.
- Your revenue recognition is not simpleIt's not just invoice sent, payment received, done. There are deferrals, milestones or usage components involved.
- Your engineers are building before accounting is decidedThe GL architecture needs to be designed now, not reverse-engineered after the product ships.
- You need a chart of accounts that reflects your actual platformNot a generic QuickBooks template someone adapted from a retail business.
- You're building on Stripe, Puzzle or MercuryAnd you need the accounting layer to match how money actually moves through those systems.
- You want an advisor who can sit in an architecture reviewSomeone who can tell you which events need separate GL treatment before your CPA sees it at year-end.
- You need it designed right the first timeNot rebuilt after your auditor asks questions you can't answer.
Six distinct patterns. One common problem.
Different industries, different models, same gap: the accounting was never designed to match how the platform actually works. Standard bookkeepers can't help here. This is where Kellcat operates. Tap any pattern to see the details.
01Billing agents & provider networks
You built a platform that invoices on behalf of licensed providers. You know the money flowing through is not all yours. But the books treat it like it is, and that liability grows every month it goes unaddressed.
The most technically complex model
Billing agents & provider networks
You built a platform that invoices on behalf of licensed providers. You know the money flowing through is not all yours. But the books treat it like it is, and that liability grows every month it goes unaddressed.
The most technically complex modelThe full invoice hits Stripe. The provider portion needs to clear as a payable. The platform fee is the only revenue line that belongs to the business. When that distinction isn't built into the GL from day one, every financial statement is wrong, and every investor, auditor or acquirer who looks at the books will find it.
Examples: environmental testing networks, home inspection platforms, healthcare billing agents, restoration and remediation networks, professional services networks.
Where Kellcat comes in
The ASC 606 agent vs. principal determination gets designed first. Then the provider payable framework, Stripe Connect split payment accounting, and the multi-payer waterfall for when a third-party payer short-pays or denies and the customer becomes the secondary payer. It has to be right from the first transaction.
02Marketplace platforms
Your GMV looks impressive. Your take rate is what actually matters. If the books report gross transaction volume as revenue, income is overstated and any serious investor has an immediate red flag.
Marketplace platforms
Your GMV looks impressive. Your take rate is what actually matters. If the books report gross transaction volume as revenue, income is overstated and any serious investor has an immediate red flag.
The gross amount hits Stripe. The seller payout goes out through Connect. The platform fee is what remains. That distinction needs to be designed into the chart of accounts and journal entry framework before volume scales, because restating financials means correcting numbers already shown to people who matter.
Examples: home services marketplaces, freelancer platforms, B2B procurement networks, rental and equipment sharing marketplaces, professional services directories.
Where Kellcat comes in
Gross vs. net revenue determination, Stripe Connect seller payout accounting, and refund and dispute handling across multiple parties, with 1099-K and marketplace facilitator sales tax questions flagged for your CPA.
03SaaS & subscription businesses
The Stripe dashboard shows one number. The books show another. The CPA is asking about deferred revenue schedules that don't exist yet. This gap doesn't close on its own.
SaaS & subscription businesses
The Stripe dashboard shows one number. The books show another. The CPA is asking about deferred revenue schedules that don't exist yet. This gap doesn't close on its own.
It started with clean monthly subscriptions. Then came annual contracts, usage-based tiers, implementation fees and free trials converting to paid. Each layer added revenue recognition complexity the original chart of accounts was never designed to handle, and it doesn't get redesigned automatically when pricing evolves.
Examples: B2B SaaS, vertical software, API-first products, usage-based billing, seat-based licensing, consumption pricing.
Where Kellcat comes in
ASC 606 performance obligations and allocation, deferred revenue schedules built in Puzzle, MRR to GAAP revenue reconciliation, Stripe Billing integration without duplicate entries, and journal entry logic for upgrades, downgrades and contract changes.
04PropTech & real estate tech platforms
Tenant deposits, owner disbursements and platform revenue all move through the same infrastructure. The legal and accounting treatment for each one is completely different. Commingling them is a problem that doesn't stay quiet.
PropTech & real estate tech platforms
Tenant deposits, owner disbursements and platform revenue all move through the same infrastructure. The legal and accounting treatment for each one is completely different. Commingling them is a problem that doesn't stay quiet.
Property money is not platform money. Security deposits are a liability until the lease ends. Owner disbursements are pass-throughs that need agent treatment, just like a billing network. Platform revenue is the only line that belongs on the income statement. Mix them in the GL and the financials aren't just inaccurate; depending on state rules, they can create legal exposure.
Examples: rent collection and owner disbursement platforms, property management software, short-term rental management platforms.
Where Kellcat comes in
Trust accounting for security deposits, an owner disbursement agent model, Stripe Connect setup for owner payouts, property-level P&L reporting, and deposit liabilities kept completely separate from operating funds.
05Professional services firms on modern infrastructure
The billing and payroll platforms are modern. The accounting layer underneath them isn't. Every invoice is still treated like a simple cash transaction, and that's not how the business actually works.
Professional services firms on modern infrastructure
The billing and payroll platforms are modern. The accounting layer underneath them isn't. Every invoice is still treated like a simple cash transaction, and that's not how the business actually works.
Milestone billing, retainers, work in progress, contractor payroll through Gusto or Rippling. Each has its own accounting treatment a generic setup can't handle. The result is revenue recognized at the wrong time, WIP that never hits the books, and monthly financials that don't hold up to scrutiny.
Examples: boutique consulting, legal practices, engineering and architecture firms, staffing agencies, fractional executive networks, advisory firms.
Where Kellcat comes in
WIP tracking, milestone revenue timing, retainer deferred revenue, contractor vs. employee classification impact on the GL, and Gusto or Rippling payroll mapped into the chart of accounts.
06HealthTech & InsurTech billing platforms
The platform fee is embedded in the transaction. The insurer pays, the platform takes its fee, the provider gets the rest. Record the full payment as revenue and income is misstated in a space that can't afford that kind of error.
HealthTech & InsurTech billing platforms
The platform fee is embedded in the transaction. The insurer pays, the platform takes its fee, the provider gets the rest. Record the full payment as revenue and income is misstated in a space that can't afford that kind of error.
The treatment follows the same agent model as any billing network (ASC 606 agent determination, net revenue, provider payable), but the stakes are higher and regulatory scrutiny is real. Partial payments, short-pays and balance billing each need their own journal entry logic at the transaction level.
Examples: physical therapy, behavioral health, dental and home health practice platforms, TPA technology, managed repair networks.
Where Kellcat comes in
ASC 606 agent treatment, provider payable framework, net revenue recognition, payer payment timing, pro-rata allocation of partial payments, and journal entry logic for balance billing when a payer short-pays or denies.
Watch a payment become a journal entry.
Our demo runs sample Stripe Connect events through the same rules we use for clients. Pick a scenario (a charge, a refund, a dispute, a failed payout) and see the entry it posts.
Sample data only. No client information.
Designed right before the first transaction.
Two fintech engagements, and what changed once the accounting layer was designed first. Client names withheld.
Every dollar that moves through the platform, accounted for
- BeforeDeposits booked as revenue, provider money looked like income, clearing drifted.
- The fixOne rule set, agent treatment under ASC 606, automated posting through the Puzzle GL API.
- AfterRevenue reported net and clearing reconciled daily, with exceptions flagged before close.
Accounting designed and connected before launch
- BeforeA new platform getting ready to launch, with no accounting structure yet for how money would flow through it.
- The fixKellcat designed the accounting architecture and wrote the code and API connections that link the platform to the books.
- AfterTransactions flow into the books correctly from day one, with no cleanup after software testing and deployment.
Four phases. No hourly billing. No surprises.
Every engagement follows the same structured path, from architecture design on day one to ongoing books, dashboards and advisory as the platform grows.
Accounting architecture & GL setup
Before a single transaction posts, the accounting infrastructure gets designed: chart of accounts, journal entry framework, Puzzle configuration, and a build spec your engineering team can work from directly.
Revenue recognition framework
Your business model mapped to the right treatment: net vs. gross, agent vs. principal, point-in-time vs. over-time. Anything that needs a CPA opinion gets flagged before go-live.
Chart of accounts
Built for the platform, not adapted from a retail template. Stripe clearing, provider payables, deferred revenue, transit accounts and platform fee revenue, structured around how money actually moves.
Journal entry framework
Every payment scenario mapped to exact entries, with account names, debits and credits, and the system event that triggers each one. Written so engineers can build to it directly.
Puzzle setup
Chart of accounts configured in Puzzle, with the API integration documented: what data to push, in what format, on which event. Native Stripe sync turned on or off to fit the architecture.
Mercury integration
Dedicated Mercury account setup, Puzzle bank sync, and Mercury webhook documentation for deposit confirmation, so every settled transaction matches in the GL without manual lookups.
Dev team build spec
A complete Puzzle or Mercury API reference with full JSON payload examples for every payment scenario. Engineers build to a written spec, not to notes nobody took during a call.
Clean Books: ongoing bookkeeping & reconciliation
Every Stripe, Mercury and Puzzle account reconciled monthly. Every payment scenario covered. Investor-ready financials without a last-minute scramble at year-end.
Monthly reconciliation
All Stripe, Mercury and Puzzle accounts reconciled every month: full pay, short-pay, recovery, refunds, chargebacks and disputes. Nothing falls through, because the framework was designed to cover them all.
Financial statements
Investor-ready P&L, balance sheet and cash flow from Puzzle. Net revenue only, with gross transaction volume tracked separately as an operating metric.
Deferred revenue tracking
A monthly deferred revenue roll-forward for subscription businesses, with recognized and unearned revenue clearly separated so the books show the true position, not just cash collected.
CPA coordination
Clean books and organized documentation at year-end. Your CPA gets what they need without billing hours to sort through raw Stripe exports.
System maintenance
The journal entry framework and chart of accounts updated as the platform evolves. New payment scenarios documented and configured before they create reconciliation problems.
Clear Picture: custom business dashboard
A live dashboard built around the platform's actual metrics. Net revenue, deferred revenue, MRR vs. GAAP and cash position in one place, updated automatically.
Fintech metrics dashboard
Built in Databox around net revenue vs. gross transaction volume, platform fee revenue, provider payable aging and MRR vs. GAAP revenue. Every number a founder or investor cares about, at a glance.
Deferred revenue visibility
Live deferred revenue balance and monthly roll-forward without opening a spreadsheet, tracked automatically instead of rebuilt at quarter-end.
Automated data feeds
Connected directly to Puzzle, Stripe and Mercury. No manual exports, no spreadsheet upkeep, no stale numbers behind current decisions.
Investor-ready layout
Answers the questions investors and lenders ask: growth rate, net revenue trend, cash position and platform fee contribution.
Dashboard maintenance
The dashboard evolves with the platform: new metrics, updated feeds, a refined layout. Plus a KPI report every two weeks and a monthly video walkthrough.
Confident Decisions: cash flow advisory
Up to two calls a month with someone who has already reviewed the books and knows what the dashboard is showing. No prep required. The conversation is about what the numbers mean and what to do next.
Up to two advisory calls a month
On a rhythm that fits your business, with a quarterly KPI review. Live dashboard review, a GL health check, and a focused conversation on what the numbers are telling you.
GL health monitoring
Every session starts with the books. Reconciliation gaps, unusual entries and system anomalies are caught before they compound.
Cash runway, burn & 13-week forecast
A weekly cash report with runway, burn rate and a rolling 13-week forecast. Know how long cash lasts at current spend before investors ask.
Scenario forecasting
Models built on your actual revenue architecture. See how new pricing tiers, fee changes or growth plans affect net revenue and runway before you commit.
System evolution support
New payment scenarios, pricing models or integrations get documented and configured before they hit the books.
CPA & investor prep
Year-end ready books, a clean audit trail and organized documentation, whether you're heading into a funding round, a tax filing or an investor review.
The difference between a bookkeeper and an accounting architect.
Is your Stripe Clearing account at $0?
It should be, every day. If it isn't, money is booked to the wrong place: revenue counted gross, fees missed, or refunds that never reached the books.
Why it happens
Your Stripe integration is probably working. It just wasn't built for a marketplace. QuickBooks, Xero and Puzzle sync charges, fees and payouts, but a standard bookkeeping setup can't tell your fee from your providers' money. Kellcat adds the accounting rules that can, on top of the setup you already use.
Three quick checks
- Does Stripe Clearing end each month at $0?
- Is your platform fee the only revenue line, with provider money held as a liability?
- Can you trace one customer payment to its payout and fee?
If any answer is no, book a books review and we'll find where it drifts.
Book a free books reviewTransparent pricing. No hourly billing.
Every engagement is scoped before any work begins. The complexity of the platform, the number of payment scenarios and the systems involved all affect scope, which is why pricing is confirmed after a free discovery call, not listed on a rate card.
Accounting architecture & GL setup
The foundation everything else depends on, scoped after discovery because no two platforms move money the same way.
Scenarios, platforms and model complexity set the scope. Everything is agreed in writing before work begins.
Priced after the discovery callClean Books
Priced once Phase 1 is complete and the live system has been reviewed. Volume and complexity set the rate.
Every Stripe, Mercury and Puzzle account covered. The number you agree to is the number on the invoice every month.
Priced after Phase 1Clear Picture dashboard
A one-time build plus a monthly rate that keeps the dashboard current and includes a KPI report every two weeks.
Built around net revenue, deferred revenue, provider payable aging and MRR vs. GAAP. Both prices confirmed before the build.
Scoped after discoveryConfident Decisions advisory
Scoped once Clean Books is running. Advisory built on reconciled numbers, not spreadsheets pulled together before the call.
Weekly KPI and cash reports, a 13-week forecast, up to two advisory calls a month, with a quarterly KPI review, scenario forecasting, CPA and investor prep.
Scoped after Layer 1Fintech accounting, answered.
Do you replace our CPA?
No. Kellcat designs the accounting system and keeps the books; your CPA handles tax and any formal opinions. Questions that need a CPA's judgment, like agent vs. principal or sales tax, get flagged and documented before go-live, and your CPA gets clean, organized books at year-end.
Do we have to use Puzzle?
No. Kellcat works across QuickBooks Online, Xero or Puzzle and matches the platform to how your business works. Puzzle for investor-track startups; QuickBooks Online or Xero for businesses staying lean. Puzzle's API makes it a strong fit for platforms that post entries automatically, but the accounting rules work on any of them.
Can you work directly with our engineering team?
Yes, that's the point. Phase 1 ends with a written build spec: the events that trigger each journal entry, the exact entries, and full JSON payload examples for the Puzzle or Mercury API. Kellcat can join architecture reviews to answer accounting questions as they come up.
We already have Stripe synced to our books. Why isn't that enough?
The sync moves the data well, but it was built for a business selling its own products. It doesn't know which part of a charge is your fee, that a provider payout settles a liability, or that Stripe Clearing should end at $0. That's the layer Kellcat adds.
We're pre-launch. Is it too early?
It's the best time. Designing the accounting before the first transaction costs far less than restating books later, and your engineers build it right the first time instead of reworking it after testing.
How is pricing set?
Phase 1 is a flat fee scoped after a free discovery call. Monthly layers are priced once the live system has been reviewed. Everything is agreed in writing before work begins, and there's no hourly billing.
What happens on the discovery call?
Thirty minutes, free, no prep needed. Kellcat reviews your business model, your stack and your payment scenarios, then tells you exactly what Phase 1 would cover.
Quick answers
Common questions
How does bookkeeping handle revenue recognition for a fintech company?
For a fintech, not all the cash moving through the platform is revenue. Good bookkeeping separates customer funds and pass-through payments from the fees the company actually earns, and records revenue when it is earned under ASC 606 rather than when cash lands. Kellcat maps each payment flow, such as Stripe Connect payouts, platform fees, refunds and chargebacks, to the ledger so revenue, liabilities and cash reconcile every month.
- Each payment scenario gets a documented journal-entry pattern, so month-end close is repeatable.
- Your CPA or auditor signs off on the revenue recognition policy; Kellcat keeps the books consistent with it.
Book a free Discovery Call to talk through your platform.
General information, not tax or legal advice.
Ready to get the accounting layer right?
Book a free discovery call. Kellcat will review your business model, your stack and your payment scenarios, and tell you exactly what Phase 1 would cover. No generic proposals. No pressure.
30 minutes · Free · No prep needed