All chapters Part VIII · The company
Chapter 41

Taxes and Financial Admin

The single decision that saves a global software business the most pain is who acts as merchant of record, because it decides whether sales tax in dozens of countries is your problem or someone else's. Get that right and most of this chapter becomes a monthly bookkeeping habit instead of a crisis.

This chapter describes categories and decisions. It is not tax or financial advice. Tax depends on your jurisdiction, your structure, and your specifics. Use this to know what applies and what to ask; take the actual numbers to an accountant.


The concept

Financial admin for a software business is four habits and one big decision:

 THE BIG DECISION   who is merchant of record — you, or a platform?
 BOOKKEEPING        record every transaction, categorised
 TAXES              income tax, sales tax/VAT/GST, and their deadlines
 RUNWAY             how long your money lasts

Most of it is boring and cheap to get right if you start early, and expensive to fix if you don't.

⭐ Merchant of record: the decision that removes global tax pain

When you sell software globally, someone has to collect and remit sales tax / VAT / GST in every jurisdiction where you have customers, and the rules differ by country, sometimes by the customer's location, and the thresholds are low.

You are MoR (Stripe, direct)A platform is MoR (app stores, Paddle, Lemon Squeezy)
Feelower (~2.9%)higher (~5%, or the 15-30% store cut)
Global sales tax / VATyour problem, everywheretheir problem
Registration & remittanceyou register in each jurisdictionthey handle it
Invoicing, complianceyourstheirs

For a solo founder or small team selling globally, letting a platform be merchant of record is usually worth the extra fee. Registering for and remitting VAT/GST across dozens of countries is a genuine ongoing burden, and crossing a threshold in a country you weren't tracking turns it into an expensive surprise.

App stores are already your merchant of record for in-app purchases, they handle the tax. This is a quiet, large benefit of selling through them that founders rarely credit.

📐 The merchant-of-record decision quietly determines whether global sales tax is your problem or someone else's. For a solo founder or small team selling worldwide, letting a platform be MoR trades ~2% in fees for not having to register and remit VAT/GST across dozens of jurisdictions, almost always worth it until you have a finance function.

The taxes you'll actually meet

Bookkeeping: the cheap habit that saves the crisis

Runway and burn

Even a bootstrapped solo founder should know:

 runway (months) = cash on hand ÷ monthly net burn

Your time is a real cost even when unpaid. Knowing your runway turns "I'll figure it out" into a deadline, and a deadline is what forces shipping and charging (Chapters 5, 7).

Pre-revenue vs post-revenue


📐 Best practice

Choose merchant of record deliberately, usually let a platform handle it when selling globally and small.

Complete the developer-account tax setup early so your first payout isn't blocked.

Separate business and personal finances from day one.

Categorise transactions as they happen.

Keep receipts for deductibles.

Reconcile monthly.

Track deductible expenses, software, hardware, contractors, hosting.

Know your runway.

Get an accountant once revenue is real, before your first tax deadline, not after.

Set aside tax as you earn, so the bill isn't a shock.


💀 Common mistakes

Being your own merchant of record globally, then discovering VAT/GST liability across countries you never tracked.

Not doing the developer-account tax setup, your first payout is held.

Mixing personal and business money. Wrecks accounting; risks your liability shield.

Bookkeeping in a year-end panic. A week of pain that an hour a month prevents.

Losing receipts, deductions you can't claim.

Not setting aside tax, the bill arrives and the money's spent.

No idea of runway. "I'll figure it out" with no deadline.

Ignoring your time as a cost. Free-looking channels and unpaid founder hours are real burn.

Getting an accountant too late, after a deadline is missed.

Assuming a tax rule from another country applies to yours.


The professional workflow

 1. CHOOSE MERCHANT OF RECORD
    global + small → platform-as-MoR is usually worth the fee

 2. DEVELOPER-ACCOUNT TAX SETUP so payouts aren't blocked

 3. SEPARATE BUSINESS BANKING from day one

 4. BOOKKEEPING HABIT
    categorise as you go · keep receipts · reconcile monthly

 5. TRACK DEDUCTIBLE EXPENSES

 6. KNOW YOUR RUNWAY (cash ÷ net burn), and treat time as cost

 7. SET ASIDE TAX as you earn

 8. POST-REVENUE
    accountant before the first deadline · sales-tax obligations if you're MoR

 9. REVIEW quarterly: burn, runway, upcoming deadlines

Tools, websites & costs

NeedToolCost
Merchant of recordPaddle, Lemon Squeezy, app stores~5% / store cut
Payments (you as MoR)Stripe + Stripe Tax2.9% + tax add-on
Sales-tax automation (if MoR)Anrok, Quaderno, TaxJar0.5%+ / $$
BookkeepingWave (free), QuickBooks, Xero$0-30/mo
Expense trackingYour bookkeeping tool, Ramp, Expensify$0-$$
Business bankingMercury, Wise, local banks$0-low
Financial modellingA spreadsheet, Causal$0-$$
AccountantLocal, or startup-focusedVaries

Pre-revenue, your financial admin can be a free bookkeeping tool and a spreadsheet. The costs (accountant, sales-tax automation) arrive with revenue, which is the right time to pay them.


Alternatives & trade-offs

Platform-as-MoR vs Stripe. MoR removes global tax at a ~2% premium. Stripe gives control, lower fees, better data, and hands you global tax compliance. Global and small: MoR. Domestic or with a finance function: Stripe.

DIY bookkeeping vs accountant vs bookkeeper. DIY (Wave, spreadsheets) is fine pre-revenue and while transactions are few. A bookkeeper handles the monthly habit; an accountant handles tax strategy and filing. Add each as complexity grows.

Cash vs accrual accounting. Cash is simpler and fine for most small software businesses; accrual is required at scale or for some entities. Your accountant will tell you which, another reason to get one.

Set aside tax vs pay quarterly estimates. Depending on jurisdiction and entity you may owe estimated taxes during the year, not just at filing. Setting money aside as you earn covers both.


Checklist


📓 Case Study: the first brush with tax machinery

Project: SOLIS. Another thin case study, honestly, a pre-revenue project never actually files a tax return or remits sales tax. But it hit the first piece of the machinery exactly where this chapter says it arrives: at the point of trying to get paid.

Merchant of record was handled by the platform, by default and to the project's benefit. Selling through the app store (via a subscription layer) meant the store was the merchant of record, it collects and remits VAT/GST worldwide. This is the quiet advantage this chapter highlights: an app founder selling through the stores inherits global tax handling without doing anything, where a founder selling the same product directly via Stripe would have owned VAT registration across dozens of countries themselves. The project got the low-pain path essentially for free.

The developer-account tax setup was recognised as a gate. The store's Paid Apps agreement, required before any money can be collected, needs bank and tax details, and it was noted as a blocker sitting on the developer's side:

the Paid-Apps agreement needs the user's bank/tax info… products are created in App Store Connect once the developer account is active.

That is exactly the first tax paperwork most app founders meet, and it can hold your first payout. It arrived, correctly, at the take-money trigger, not before, not too late.

The infrastructure had near-zero running cost. The stack ran at ~$0/month at launch scale (Chapter 31), so pre-revenue financial admin was genuinely just tracking a handful of fixed costs, a developer account and a domain, plus one month of a content tool. There was very little to book-keep, which is the correct state for a pre-revenue project.

⚠️ Deviation / gap, mostly by circumstance: no entity, no business bank account, no bookkeeping system, no accountant. For a pre-revenue solo project this is defensible (Chapter 39), and the moment revenue arrived, the separation-of-finances and set-aside-tax habits would have become necessary. The project never reached that moment, so these were never exercised, which is the honest status, not a failure.

🚩 Everything downstream of first revenue is untested. No sales tax was ever remitted (the store would have handled it), no income tax return filed, no runway pressure felt because there was no burn beyond a few fixed subscriptions. What the case study genuinely shows is the one decision that mattered pre-revenue, letting the platform be merchant of record, being made correctly and effortlessly, and the one gate (developer-account tax setup) arriving where the model predicts.


Lessons

  1. ⭐ Merchant of record is the decision that removes global tax pain. Selling globally and small, let a platform handle it.
  2. App stores are already your merchant of record for in-app purchases, a large, quiet benefit.
  3. Do the developer-account tax setup early. It can gate your first payout.
  4. Separate business and personal finances from day one of having a business.
  5. Categorise transactions as they happen. An hour a month beats a year-end week.
  6. Keep receipts; track deductibles.
  7. Know your runway, and count your time as cost. A deadline forces shipping.
  8. Set aside tax as you earn.
  9. Get an accountant when revenue is real, before the first deadline.
  10. Pre-revenue financial admin is minimal, and that's correct. The habits become necessary the moment money arrives.

Next: Chapter 42: Customer Support →

Useful? Share this chapter