Micro-SaaS and API Bookkeeping: Usage-Based Billing, Processor Reconciliation, and Why 70% Margins Still Need Real Books

Your API just crossed $18,000 in monthly recurring revenue on 340 customers, your Stripe dashboard shows a healthy 78% gross margin, and your accountant asks to see your revenue recognition schedule. You open your bookkeeping and there is nothing to show — just a checking account with deposits that never match your Stripe reports and a spreadsheet you stopped updating in March.

That gap is where Micro-SaaS bookkeeping breaks. The business looks deceptively simple — no inventory, no warehouse, margins that would make a retailer weep — but the money moves in ways a standard "income minus expenses" ledger cannot capture. Metered usage, prepaid credit packs, processor fees netted before you ever see the cash, global tax collected on your behalf, and deferred revenue that makes your bank balance lie to you. Get any of it wrong and you misstate revenue, overpay taxes, or price your next tier on fantasy math.

This guide covers the bookkeeping that actually fits a Micro-SaaS or API business: how to structure usage-based billing so your books stay clean, how to reconcile payment processors without losing your mind at month-end, and why even a 70%+ margin business needs real accrual accounting from day one.

Why Micro-SaaS Books Are Harder Than They Look​

Traditional small businesses record a sale when cash changes hands or an invoice is paid. A Micro-SaaS rarely does either. Consider a typical month for a small API or AI tool:

• 120 customers on a $29/month Starter plan with 500 included API calls
• 40 customers on a $99/month Pro plan with 5,000 included calls plus $0.02 per call overage
• 60 customers who bought prepaid credit packs ($49 for 2,000 credits) and spend them irregularly
• A handful of enterprise customers on annual prepay that you collected in January

On any given day you collect cash that is not yet revenue, recognize revenue you collected weeks ago, owe processor fees you never invoiced, and deliver usage that has not been billed yet. A cash-basis set of books collapses all of that into "money in, money out" and tells you almost nothing about whether the business is actually growing.

The Three Things That Make Micro-SaaS Different​

Variable cost per unit. Every API call, AI generation, or webhook delivery costs you something — an upstream LLM token fee, compute, bandwidth, or a third-party API you resell. Flat subscriptions hide that variability until a power user consumes 50 times the average and erases the margin on an entire cohort. Your books need to show cost of goods sold (COGS) per unit, not just total hosting spend.

Variable revenue per customer. Two customers on the same $29 plan can generate wildly different revenue once overages and credit top-ups kick in. If you book only the subscription fee and treat overages as incidental, you understate revenue from your best customers and misprice your tiers.

Prepaid and deferred revenue. Credit packs and annual plans give you cash today for service you will deliver over weeks or months. That cash is a liability — unearned revenue — until the customer actually consumes the credits or the service period elapses. Booking it as income on receipt overstates profit now and understates it later, which matters the moment you need a loan, a valuation, or a tax return that matches reality.

Choosing a Billing Model That Your Ledger Can Live With​

The billing model you pick is a bookkeeping decision as much as a pricing decision. Each one creates different recognition, reconciliation, and tax events.

Flat Subscription​

Everyone pays the same fee regardless of usage. Bookkeeping is trivial: one recurring invoice per customer per period, revenue recognized evenly over the period. The problem is economic, not accounting — you subsidize heavy users and leave money on the table with light ones. Flat pricing works as a learning phase while you measure consumption, but it rarely survives once you understand your per-unit cost.

Pure Usage-Based (Pay Per Call, Per Token, Per Seat-Hour)​

You meter consumption and invoice after the fact. Revenue and cost move together, which is satisfying on a spreadsheet and terrifying to an enterprise buyer who cannot forecast spend. From a bookkeeping standpoint, pure usage creates unbilled revenue at every month-end: service delivered but not yet invoiced. You need to accrue it. You also need robust metering that your ledger can trust, because the invoice is only as accurate as the counter.

Best suited to developer-facing APIs where the buyer is technical enough to forecast usage. Less suited to prosumer tools where predictability sells.

Hybrid: Subscription Base + Included Quota + Overage​

This is the default that has emerged for most Micro-SaaS and AI tools: a monthly subscription includes a quota (credits, calls, generations); consumption beyond the quota bills at a per-unit overage rate, often 2 to 4 times your actual cost.

Why it wins operationally: buyers get predictability for typical usage, you capture more revenue from power users without scaring away light ones, and gross margins are protected because overages are priced well above cost. For your books, hybrid billing means two revenue streams per customer — recurring subscription revenue recognized ratably, and variable overage revenue recognized when the overage occurs. Keep them in separate ledger accounts. When you later ask "what percentage of MRR is really variable?" you will have the answer without digging through invoices.

A practical tier sketch:

• Starter $19/month — 500 generations included, $0.05 per generation over
• Pro $49/month — 2,000 generations included, $0.04 per generation over
• Scale $99/month — 6,000 generations included, $0.03 per generation over

Size each quota so roughly 80% of customers at that tier never hit the limit. The product feels unlimited; the 20% who do hit the limit fund your infrastructure.

Prepaid Credit Packs​

Customers buy credits upfront and spend them over time. Credits give you better cash timing — you collect before delivering — and a natural upsell trigger when balances run low. But every credit sale creates deferred revenue on day one. You debit cash, credit a liability account like Liabilities:UnearnedRevenue:CreditPacks, and only move it to Income:CreditUsage as credits are consumed. Selling 1,000 packs at $49 each and booking $49,000 as income that month is fine for your bank account and wrong for your profit and loss.

A common structure that converts well:

• 500 credits for $14 (never expires)
• 2,000 credits for $49 (14% discount)
• 10,000 credits for $199 (29% discount, priority processing)
• Monthly refill: 1,500 credits for $39/month with a 10% bonus over the equivalent pack

The pack buyers who top up regularly are your best candidates for the monthly refill — make the per-credit math obvious and let the upgrade sell itself.

Outcome-Based Pricing​

Charge per successful outcome — per resolved support ticket, per converted lead, per completed workflow. It is compelling when the outcome is measurable and valuable, but it demands infrastructure to track and prove that the outcome actually happened. For bookkeeping, each "outcome" is a performance obligation you satisfy at a point in time, and you need audit trails to support every invoice.

Payment-Processor Reconciliation: Where the Money Actually Goes​

If you use Stripe, Paddle, Lemon Squeezy, or a Merchant of Record like Fungies or Dodo Payments, the cash that lands in your bank account is never the number your dashboard shows. A typical Stripe payout looks like this:

• Gross sales: $12,400
• Less Stripe fees (2.9% + $0.30 per charge and 0.5% billing fee): -$412
• Less refunds: -$180
• Less disputes and chargebacks: -$45
• Net payout to your bank: $11,763

If you book that $11,763 as "revenue," you have understated income by $637 and completely hidden your processing costs, refund rate, and dispute exposure from your own financials.

The Reconciliation Pattern​

Reconcile to the processor report, not to the bank deposit. At month-end:

1. Import the processor's settlement report — gross sales by product/plan, fees, refunds, disputes, tax collected. Every reputable processor provides a CSV or API export with these columns broken out daily.

2. Book gross to the correct income accounts. Subscription base, overage, and credit-pack redemptions each get their own account. This is the revenue your customers actually paid before anyone took a cut.

   Assets:Bank:Checking                    $11,763
   Expenses:ProcessorFees:Stripe              $412
   Assets:AccountsReceivable:RefundsPending   $180
   Expenses:Disputes:Chargebacks              $45
     Income:Subscriptions:Starter
     Income:Subscriptions:Pro
     Income:Usage:Overage
     Income:CreditPacks:Redeemed

   Exact account names are yours to choose, but the principle is fixed: gross in, fees and refunds out, net to bank.

3. Book fees as an expense, not a net against revenue. Processor fees are a cost of collecting revenue, not a reduction of revenue. Netting them hides your true take rate and makes cohort margin analysis impossible.

4. Handle tax collected by a Merchant of Record correctly. If you sell through a Merchant of Record, the MoR is the legal seller and handles VAT, GST, and US sales tax collection and remittance. The "tax" line on your MoR settlement is not your liability to remit — it is their obligation — but you still need to record it so your gross ties to the report and your net ties to the bank. Some founders net it out of revenue; cleaner is to book it to a pass-through liability that zeroes when the MoR remits.

5. Track refunds and chargebacks separately. A refund is a reversal of revenue; a chargeback adds a dispute fee on top. If you net them together you cannot answer the question "is our refund rate climbing?" and you cannot spot a fraud pattern early.

Common Reconciliation Mistakes​

Booking payouts as revenue. The most common error for solo founders. It understates income, overstates margin (because fees vanish), and creates a mismatch between your 1099-K and your books at year-end.

Ignoring pending payouts. Processor balances that have been charged but not yet paid out are accounts receivable. If you close your books on January 31 and Stripe has not yet paid out January 29–31, that revenue belongs to January, not February.

Forgetting application fees on connected accounts. If you run a marketplace or take an application fee on top of a managed payment, the application fee is your revenue and the underlying charge is not. Book only what is yours.

Not reconciling credit-pack sales to deferred revenue. Every credit-pack sale should have a matching liability entry that unwinds as credits are spent. If your deferred balance grows every month but your recognized revenue does not, you are selling packs faster than customers consume — useful signal for cash flow, invisible if you booked packs as income on sale.

Why 70%+ Gross Margins Still Demand Real Books​

It is tempting to think a high-margin software business does not need sophisticated bookkeeping. Hosting is cheap, there is no inventory, and profit seems to take care of itself. Three realities correct that quickly.

What Actually Sits in COGS​

For a Micro-SaaS or API business, COGS is not "hosting." It is every cost that scales directly with usage and would not exist if you served zero customers:

• Upstream API and LLM token costs (OpenAI, Anthropic, or your own GPU inference)
• Metered infrastructure (per-request compute, egress bandwidth, image generation seconds)
• Third-party data or enrichment APIs you resell
• Per-seat license costs for embedded components

Hosting that does not scale with usage — your static front end, admin dashboards, fixed databases — is operating expense, not COGS. Getting this split right is what lets you calculate a true gross margin per plan and per customer. A $29 Starter plan with 500 included generations might cost you$1.50 in LLM and compute at average usage; the same plan with a power user at 2,000 generations could cost $12. If both show the same "gross profit" in your books, you cannot price correctly.

Target overage pricing at 3 to 5 times your per-unit COGS. If a generation costs you $0.003 all-in, price overages at$0.01 to $0.015. That sustains a 70 to 80% gross margin on overage and protects you when model costs spike or a customer discovers automation.

Deferred Revenue Makes Your Bank Balance Lie​

A Micro-SaaS that sells annual prepays and credit packs can look cash-rich and profit-poor — or the reverse — depending on when you collect. Example: you sell 40 annual Pro plans at $990 each in January, collecting$39,600. On a cash basis, January is your best month ever. On an accrual basis, you earned $3,300 in January and owe$36,300 in future service. If you spend January's cash as if it were January's profit, you will be short by December.

Accrual accounting fixes this by recognizing revenue when you satisfy the obligation, not when you collect. Book the annual sale as:

• Debit cash, credit deferred revenue (a liability)
• Each month, debit deferred revenue, credit subscription income for one twelfth

The same logic applies to credit packs: revenue when spent, not when sold. It is more work, and it is the difference between knowing whether you are growing and merely watching cash slosh.

Unit Economics Decide Your Next Decision​

Investors, lenders, and even you at 11 p.m. deciding whether to raise prices all ask the same questions:

• What is net revenue retention — are existing customers spending more over time?
• What is gross margin by plan, and which tier subsidizes which?
• What is customer acquisition cost payback when you include true COGS and processor fees?
• What is deferred revenue and does it cover the next two months of obligations?

None of those are answerable from a checking account balance. They require a ledger that separates subscription from overage, gross from net, earned from deferred, and COGS from OPEX. Plain-text accounting shines here because those categories are explicit accounts in a file you control, version-tracked in git, auditable at any point — not buried in a dashboard that changes its definitions without notice.

A Minimal Chart of Accounts That Works​

You do not need a 200-line chart of accounts. You need enough structure to answer the questions above:

• Income:Subscriptions:Starter / Pro / Scale
• Income:Usage:Overage
• Income:CreditPacks:Redeemed (pack sales themselves go to Liabilities:UnearnedRevenue:CreditPacks first)
• Expenses:COGS:Inference (LLM / model costs)
• Expenses:COGS:MeteredInfra (per-request compute, bandwidth)
• Expenses:COGS:DataAPIs (third-party APIs resold)
• Expenses:ProcessorFees:Stripe (or Paddle / MoR)
• Liabilities:UnearnedRevenue:AnnualPlans and Liabilities:UnearnedRevenue:CreditPacks
• Assets:AccountsReceivable:ProcessorPending (earned but not yet paid out)

Start there. Add accounts when you have a question the current structure cannot answer, not before.

Month-End Close for a One-Person SaaS​

You do not need a finance team to close books properly. You need a repeatable checklist that takes an hour once a month:

1. Pull the processor settlement report for the full month and book gross by product, with fees, refunds, and tax broken out.

2. Reconcile bank deposits — every payout in the bank should match a settlement batch in your ledger. Flag any pending batch that was charged but not yet paid out.

3. Update deferred revenue schedules. For each annual plan and credit pack, move the earned portion from liability to income. If credit packs have no expiry, consider a breakage policy for stale credits (unredeemed packs older than 12–18 months) and document it — this is where accounting judgment lives, so write it down.

4. Accrue unbilled usage. If you bill overages in arrears, estimate or meter the unbilled amount at month-end and book it to accrued revenue.

5. Reconcile COGS. Match upstream API invoices (OpenAI, cloud provider) to the usage period they cover, not the date you paid. A $2,400 inference bill paid on the 5th for last month's tokens belongs to last month.

6. Review failed payments and churn. Failed charges that will be retried are not lost revenue yet; put them in a dunning bucket. After your retry window closes, write them off and record churn accurately.

7. Reconcile deferred and accrual balances. Your deferred liability should be reconcilable to a schedule — every dollar tied to a specific customer and service period. If the total drifted from the schedule, something was booked twice or not at all.

Tax and Compliance Without a Finance Team​

If you sell only to US customers and stay under state economic nexus thresholds, a direct Stripe integration is manageable. The moment you sell globally, tax compliance multiplies: VAT in the EU at the customer's rate, GST in Australia, HST in Canada, varying treatment of SaaS across US states, and distance-selling thresholds that trigger registration obligations you did not know existed.

A Merchant of Record absorbs that complexity. They collect and remit tax in each jurisdiction, issue compliant invoices, handle chargebacks, and become the seller of record so you never file a foreign VAT return. The trade-off is a higher transaction fee (typically 4 to 5% plus a fixed amount) versus Stripe's 2.9% + $0.30 plus a separate tax calculation add-on. For a small team shipping globally from day one, the MoR fee is almost always cheaper than the engineering and accounting time to do it yourself — and far cheaper than getting it wrong.

If you stay on Stripe directly, at minimum: register under the EU VAT One-Stop Shop (OSS) when you have any EU customers, enable Stripe Tax for calculation, file quarterly OSS returns, track US economic nexus by state (many states use a $100,000 sales threshold), and keep compliant records for every jurisdiction you sell into. Calculation without remittance helps you quote the right price but does not satisfy the obligation.

Also plan for income tax: processor payouts are gross before fees, so your 1099-K will reflect the higher number. If you booked only net deposits, your return will not tie to the form and you will spend extra hours explaining the difference. Book gross and the tie-out is arithmetic.

What Clean Books Buy You​

Clean books for a Micro-SaaS do not just keep you compliant. They give you the answers you need to run the business: which plan has the best margin after true COGS, whether credit packs or subscriptions drive better payback, when to raise the included quota versus the overage price, and whether that "profitable" month was actually just annual prepays masquerading as growth.

Set up the separation — subscription versus overage versus credit redemption, COGS versus OPEX, earned versus deferred, gross versus net of fees — in your first month, not your twelfth. Retrofitting a year of netted payouts and misclassified hosting is the work that makes founders wish they had started with a real ledger.

Simplify Your Financial Management​

As your Micro-SaaS moves from scrappy metered billing to a full hybrid pricing engine, maintaining clear financial records is what keeps pricing decisions honest and tax season calm. Beancount.io provides plain-text accounting that gives you complete transparency and control over your financial data — every subscription tier, credit pack liability, processor fee, and COGS line version-controlled in a ledger you own. Get started for free and see why developers and finance professionals are switching to plain-text accounting.