Cost to Build Accounting Software Like Wave: What Small Business Founders Actually Pay

A bookkeeping firm in Calgary runs a recurring workflow for 65 small business clients. Every client's books live in Wave. Every month, the bookkeeper logs into each Wave account, reconciles the bank feed, categorizes expenses, and generates reports. The bookkeeper does not own the data -- Wave does. There is no API to pull client records into a consolidated dashboard, no webhook to trigger automation when a client creates an invoice, and no way to white-label the client-facing experience. The bookkeeper has been looking for a way to offer a branded client portal for two years. The choice is build one or keep using a product that was designed for the small business owner, not for the firm serving them.

This article is for the people in that position: bookkeeping firms who want a branded client accounting portal, vertical SaaS founders who need an accounting layer embedded in their product, and agencies or freelance platforms that have grown to the point where Wave's payment processing fees are a meaningful cost. It covers what it costs to build accounting software from scratch, what the double-entry accounting engine actually requires in a technical build, and where the math tips from "use Wave" to "build past it."

How much does it cost to build accounting software like Wave?

Building accounting software costs $55,000 to $220,000 depending on scope. A V1 with invoicing, expense tracking, and payment processing takes 10--14 weeks. A full platform with a double-entry accounting engine, bank reconciliation, payroll, and AI receipt scanning takes 24--32 weeks.

What moves cost within these ranges: whether the double-entry engine must be built from scratch (4--6 weeks of dedicated engineering) or whether a lighter transaction-log model is acceptable for V1, whether bank feed import is in scope at launch (Plaid access costs $2,000--$5,000/year and requires a data access agreement), whether payroll must handle both US and Canadian tax calculations, and whether the platform needs a public API layer for bookkeeping integrations. Cross-platform mobile for a receipt scanning feature saves $20,000--$35,000 versus native iOS and Android apps built separately.

According to SCORE's 2023 research on small business sustainability, 82% of small businesses that fail cite cash flow problems as a contributing factor, and 40% of small business owners spend more than 80 hours per year on accounting tasks. That time burden is what Wave reduced -- and it is what a vertical SaaS with embedded accounting eliminates entirely for the buyer.

How Wave makes money -- and what you control when you build

Wave's core product is free. Invoicing, double-entry accounting, expense tracking, and receipt scanning cost nothing. Wave monetizes through two primary channels and one growing advisory layer.

The first channel is Wave Payments: credit card processing at 2.9% + $0.30 per transaction, bank transfer (ACH) at 1% with a $1 minimum. A small agency processing $600,000/year in client payments through Wave Payments pays $17,400/year in processing fees at the card rate. The bank transfer rate is lower, but clients paying by card are the norm for retainer-based work. Wave earns on every dollar that flows through the platform.

The second channel is Wave Payroll: $20/month base plus $6 per active employee per month. A 15-person team pays $110/month ($1,320/year). Wave Payroll handles direct deposit, automatic tax filing, and year-end T4/W-2 generation in Canada and the US. The payroll module is where Wave's recurring revenue concentrates -- payment processing is transactional, but payroll is monthly.

The third channel is Wave Advisors: human bookkeeping and tax advisory services layered on top of the free software. This moves Wave from SaaS into a professional services hybrid -- a model that H&R Block (which acquired Wave in 2019 for approximately $405 million) was well-positioned to scale.

When you own the platform, the economics shift. Payment processing routes directly through Stripe at the same 2.9% + $0.30 rate -- but at $1M/year in volume, Stripe offers custom pricing that drops below 2.5%. There is no platform margin sitting above the card network rate. Payroll processing costs shift to a payroll API provider (Gusto's embedded payroll runs $6--$12/employee/month at wholesale; Finch provides payroll read/write access across providers). You eliminate the per-transaction rake that compounds at scale. You also own the data model -- client financial records, journal entries, and reconciliation history are in your infrastructure, not in Wave's database, and accessible via your own API.

The revenue options when you build as a product: flat-fee SaaS subscriptions per firm (bookkeeping firms, agencies), a processing margin on payments you facilitate, per-employee payroll fees, or white-label licensing to industry associations.

The Canadian Federation of Independent Business's 2023 Annual Report estimates 1.2 million small businesses in Canada use some form of accounting software -- 44% on cloud platforms. The Canadian market is underserved by Wave specifically because of provincial sales tax complexity: Wave handles GST/HST but not BC PST, Saskatchewan PST, or Quebec QST natively without workarounds.

Who builds custom accounting software instead of using Wave?

Four specific types of organizations find the economics or product limitations tip toward building.

Vertical SaaS founders who need accounting embedded in the product

A field service platform serving HVAC contractors needs invoicing embedded in the technician's job completion workflow. The technician closes the job, the invoice generates from the job record, the client pays through the app, and the revenue hits the contractor's P&L -- without the contractor ever opening a separate accounting tool. Pointing the contractor to Wave breaks this loop: they have to export job data, import it to Wave, and reconcile manually. The embedded accounting layer -- where the job data model feeds the accounting data model directly -- is a product feature, not an integration. Vertical SaaS founders building for field service, property management, legal billing, or professional services often reach this ceiling around Series A, when they realize accounting is the data layer holding everything else together.

Bookkeeping firms who want a branded client portal

A boutique bookkeeping firm managing 80 clients wants to offer clients a portal where they can view their books, download reports, and upload receipts -- under the firm's brand. Wave does not white-label. The firm either runs 80 separate Wave accounts (no consolidated view, no branded experience) or builds a thin portal layer on top. But Wave's API is read-only and limited -- it exposes a fraction of the accounting data model. Building a full branded portal requires building the accounting layer that sits beneath it.

Freelance platforms and agency networks processing high payment volume

A freelance platform connecting 2,000 independent consultants to enterprise clients processes $8M in annual contractor payments. At Wave Payments' 1% ACH rate, that is $80,000/year in processing fees. The platform's own Stripe integration at a negotiated rate below 0.5% would cost under $40,000/year for the same volume. But more importantly, the platform needs to track which contractor invoiced which client, apply platform fees, handle 1099 tax reporting for US contractors, and manage T4A slips for Canadian contractors -- all in a unified data model Wave was not built to support.

SaaS platforms in regulated industries that need GAAP-compliant reporting

A property management SaaS serving residential landlords needs to generate a GAAP-compliant income statement and balance sheet for each property, track security deposits as liabilities (not revenue), and produce owner distribution reports that reconcile rent collected against management fees and maintenance costs. Wave's accounting model handles income and expenses well. It does not handle the multi-entity, multi-property reporting structure a property management platform needs -- where each property is a separate reporting entity and owner distributions flow through an equity account, not a revenue account.

What features does an accounting software MVP need?

How the build timeline breaks down week by week

The most expensive mistake in an accounting software build is treating the double-entry accounting engine as a feature added in V2. The moment you record the first invoice or expense in V1, you have made a decision about the accounting data model. If V1 uses a simple transaction log (income entries and expense entries with category tags), migrating that data to a true double-entry journal in V2 requires rewriting every historical transaction. That migration work costs 6--10 weeks of engineering and delays V2 by a quarter.

Design the chart of accounts and journal entry schema in week one. Build V1's invoicing and expense features on top of it. The V1 user never sees the double-entry machinery -- it runs underneath the simpler UI. But when V2 adds bank reconciliation and financial reports, they pull from the same journal that V1 has been populating all along.

Weeks 1--2: Data model design. The chart of accounts hierarchy (account type, parent account, normal balance direction). The journal entry table (transaction ID, date, description, lines with account, amount, debit/credit flag). The entity model (clients, vendors, bank accounts, currencies). Payment state machine design: draft, sent, partial, paid, voided. Plaid data access agreement and API credentials.

Weeks 3--5: Invoice module. Invoice creation UI with line items, tax rates, recurring schedule options. PDF generation with firm branding. Email delivery with payment link. Invoice status tracking (draft, sent, viewed, partial, paid, overdue). Client record creation and lookup.

Weeks 6--8: Expense tracking module. Manual expense entry with vendor, date, amount, category, and receipt attachment. Expense category mapping to the chart of accounts. Basic expense report by category and date range.

Weeks 9--11: Stripe payment integration. Hosted payment page from invoice link. Card and ACH payment acceptance. Webhook handler for payment confirmation. Payment journal entry: debit bank account, credit accounts receivable, debit accounts receivable, credit revenue (two-step to handle the timing between payment received and bank settlement). Outstanding invoice report.

Weeks 12--14 (V1 launch): User roles (owner, bookkeeper, view-only). Multi-currency invoice and payment handling with exchange rate capture. Basic income/expense report. QA across the invoice-to-payment-to-report flow. Stripe Connect onboarding for new accounts.

Weeks 15--19 (V2): Double-entry engine. Bank feed import via Plaid: daily sync, deduplication, pending/settled status handling. Reconciliation engine: transaction matching, settlement-lag logic, unmatched item flagging, one-click reconcile.

Weeks 20--22 (V2): Financial report engine. Profit and loss statement query (revenue accounts minus expense accounts by period). Balance sheet query (asset accounts, liability accounts, equity accounts at a point in time). Cash flow statement. Accounts receivable and payable aging reports. Sales tax report for CRA/IRS filing preparation.

Weeks 23--32 (V3): Payroll module (US + Canadian tax tables, direct deposit via ACH, year-end forms). Multi-entity support. AI receipt scanning (OCR model integration, confidence scoring, manual review workflow). REST API and webhook layer. Bookkeeping firm portal.

What compliance does accounting software need to get right?

US GAAP double-entry accounting -- the standard that governs financial statements

Generally Accepted Accounting Principles (GAAP) in the United States require that financial statements be prepared on an accrual basis for most businesses: revenue is recognized when earned (when the invoice is issued), not when cash is received. An accounting system that records revenue only on payment receipt -- a cash-basis system -- cannot produce a GAAP-compliant income statement for a business with outstanding invoices.

For a small business accounting platform, the practical requirement is: support both cash-basis and accrual-basis accounting, let the user switch between reporting views, and ensure the underlying data model captures the timing of both the economic event (invoice date) and the cash event (payment date). A pure cash-basis system -- one that records only payments, not invoices -- satisfies the IRS for tax reporting but not GAAP for financial statements. Most SMB accounting platforms, including Wave, support both by recording invoices as receivables (accrual) and letting users filter reports by cash or accrual basis.

"The accounting data model is the most consequential architectural decision in a financial software build. Everything else -- the UI, the reports, the integrations -- derives from it. Teams that start with the user interface and build the data model to match what the screens need end up with an accounting system that looks right but cannot produce correct financial statements."

-- Paul Byrnes, CPA, CITP, as cited in the Accountex Report 2023

SOC 2 Type II -- the trust standard for fintech platforms

Any platform that handles accounting data for third-party clients (bookkeeping firms, multi-client portals) will eventually face a SOC 2 Type II audit requirement from enterprise customers. SOC 2 requires evidence of controls across five trust service criteria: security, availability, processing integrity, confidentiality, and privacy. The audit covers a 6--12 month observation period and produces a report that enterprise buyers use to evaluate vendor risk.

The practical engineering requirements for SOC 2 readiness: encryption at rest (AES-256 on database volumes) and in transit (TLS 1.2+), role-based access controls with principle of least privilege, multi-factor authentication for all users, audit logging of every data access and change event, automated vulnerability scanning, incident response procedures, and a vendor risk management program covering Plaid, Stripe, and any payroll API provider. Building these controls from the start -- rather than retrofitting them before a customer-driven SOC 2 audit -- saves 3--4 months of remediation work and avoids the embarrassing conversation when an enterprise customer asks for the SOC 2 report and there is none.

PIPEDA and Canadian provincial privacy law

Canadian accounting software handling personal financial data is subject to PIPEDA (Personal Information Protection and Electronic Documents Act) at the federal level. Alberta, British Columbia, and Quebec have substantially similar provincial legislation that takes precedence in those jurisdictions. Quebec's Law 25 (in effect since September 2023) added requirements beyond PIPEDA: mandatory privacy impact assessments for new technology projects, data retention policies with automatic deletion, and 72-hour breach notification to the Commission d'accès à l'information.

The accounting data model in a Canadian platform must: store client financial records on servers located in Canada (or with documented consent for cross-border storage), implement data retention policies that automatically purge records after the applicable statute of limitations period (generally seven years for tax records under the Income Tax Act), and have a documented breach notification process aligned with the Office of the Privacy Commissioner's guidance.

BDC's 2022 Digital Adoption Report found that 53% of Canadian SMEs have adopted cloud-based financial management tools. The concentration in urban markets means urban-focused bookkeeping firms are ahead of the curve, but the regulatory expectations apply regardless of adoption rate.

Bank reconciliation and the settlement-lag problem

Bank reconciliation in accounting software is harder than it appears because bank transactions and accounting entries operate on different timelines. When a customer pays an invoice by ACH bank transfer on Monday, the payment may not settle in the merchant's bank account until Wednesday or Thursday. The accounting entry (debit bank, credit accounts receivable) is recorded on Monday. The bank transaction appears in the Plaid feed on Wednesday. The reconciliation engine must match a Monday journal entry to a Wednesday bank transaction and understand that they represent the same event.

A reconciliation engine that only matches on exact date equality will produce a systematic mismatch for every ACH transaction. One that allows a 5-day date window will produce false positives -- matching two different transactions that happen to be the same amount within 5 days of each other. The correct approach is a probabilistic matching model: match first on exact amount and narrow date window, then expand the date window for unmatched items, then present remaining unmatched items for manual review. Building this matching logic correctly takes 3--4 weeks of engineering and requires test data from real bank feeds, not synthetic test cases.

What technical challenges do teams consistently underestimate?

The double-entry engine must be correct before the first transaction

A common V1 shortcut: record invoices and payments as a simple transaction log (income entry, expense entry, category tag). The thinking is that the double-entry engine is a V2 problem -- add it when you need financial reports. The problem is migration. When you have 50,000 transactions in a simple log format and decide to add double-entry, you must translate every historical transaction into debit-credit journal entries. Revenue entries become debits to accounts receivable and credits to revenue accounts. Payment entries become debits to bank accounts and credits to accounts receivable. Expense entries become debits to expense accounts and credits to bank accounts or accounts payable.

This translation is not mechanical -- it requires knowledge of the account structure and the timing of each event. Teams spend 6--10 weeks on the migration and delay every other V2 feature. The correct approach: build the double-entry journal schema in week one of V1, then build the V1 invoicing and expense features as UI layers that write to the journal. Users see a simple invoicing interface; the journal runs underneath it.

Plaid's connection management is an ongoing engineering cost

Plaid's financial institution connections break. Banks update their authentication flows, change their session management, or modify their API responses. When a connection breaks, the bank feed stops importing. If the platform has no alert for broken connections, the user may not notice for days or weeks -- and the reconciliation engine has a gap in the import history that requires manual back-fill.

The Plaid integration must include: connection status monitoring with alerts when a connection goes stale, a re-authentication flow that guides the user through reconnecting broken connections, a gap-detection system that flags date ranges where no transactions were imported, and a historical import tool that can back-fill missing transactions from a date range. These edge cases account for 2--3 weeks of engineering that teams typically do not include in V1 scope but discover in the first month of production use.

Payroll tax calculations drift with legislative changes

US federal and state payroll tax rates change. State minimum wages adjust. Social Security wage bases change annually (the 2024 Social Security wage base was $168,600). New York, California, and other states change unemployment insurance rates yearly. A payroll engine that hardcodes tax rates is wrong by January 2 of every new year.

The correct payroll architecture separates tax logic from tax rates. The logic (calculate Social Security at X% up to the wage base; calculate state income tax using the withholding table for this filing status) is code. The rates (the percentage, the wage base, the withholding table thresholds) are data stored in a tax rate table with effective dates. An annual update becomes a data load, not a code change. Teams that hardcode rates spend 2--3 weeks rebuilding payroll logic every year instead of spending 2--3 hours loading a rate update.

Build vs. Wave: when does the math tip?

Keep using Wave when: you are a freelancer or small business with under 20 active clients, annual payment volume below $200,000, and no need for a client-facing portal or third-party integrations. Wave's free accounting and invoicing is genuinely capable at this scale. The cost to build and maintain a custom platform is not justified.

Use QuickBooks Online when: you need deeper reporting, multi-company support, class tracking, or integration with US payroll. QuickBooks at $35--$235/month is expensive relative to Wave but covers reporting complexity that Wave does not. For established businesses with an accountant who knows QBO, switching is a training cost with limited upside unless you have specific unmet needs.

Use FreshBooks when: invoicing is the primary product and accounting depth is secondary. FreshBooks has the strongest client-facing invoicing experience in the category -- cleaner than Wave's, better mobile experience. Its accounting depth is lighter than Wave's. For freelancers and creative agencies where the invoice is the product, FreshBooks competes directly with Wave.

Build your own when: at least two of these apply.

You are building a vertical SaaS product where accounting is a native feature, not an integration. Field service, property management, legal billing, healthcare practice management -- if your product owns the transaction that generates the invoice, you should also own the accounting layer that records it. Pointing your users to Wave creates a data gap between your operational data and their financial records.

Your bookkeeping firm manages more than 30 clients and needs a branded, consolidated portal. Wave's multi-account workflow is manual and unbranded. The build cost for a bookkeeping portal ($90,000--$130,000) represents 3--4 years of time savings for a firm billing $200/hour to clients who currently wait a week for their monthly reports.

Your payment volume exceeds $400,000/year and the processing fee is a line item your finance team notices. A Stripe integration negotiated at 2.5% saves $2,000/year at that volume. At $2M/year, negotiated card rates below 2% save $18,000/year against Wave's standard rate. The build cost pays back in 3--8 years depending on volume -- faster if you also eliminate a SaaS subscription.

According to Intuit's 2023 Annual Report, QuickBooks serves 7.4 million subscribers with average revenue per subscriber of $248/year in the US Small Business segment. Wave is the free alternative in the same market -- but the ceiling that drives businesses toward QuickBooks (deeper reporting, more integrations, accountant ecosystem) is the same ceiling that tips vertical SaaS founders toward building their own accounting layer rather than integrating either.

How does the competitive accounting software landscape stack up?

Wave is the clear leader in the free tier of the SMB accounting market. Double-entry accounting, invoicing, and receipt scanning at no charge makes it the default for early-stage freelancers and solo businesses. The ceiling: no API for builders, limited multi-currency depth, Canadian sales tax support requires workarounds, and payment processing fees compound at volume. H&R Block's ownership has not meaningfully expanded the product's technical scope since 2019.

QuickBooks Online is the market-leading paid platform with 7.4 million subscribers. Stronger reporting, stronger accountant ecosystem, deeper integrations. Weaknesses: pricing that grows aggressively at the upper tiers ($235/month for Advanced), a UI that has accumulated complexity over decades of feature additions, and the same per-seat ceiling that makes it expensive for bookkeeping firms managing many clients.

FreshBooks wins on client experience. The invoicing interface is the best in the category -- clean, mobile-first, and fast for freelancers sending 5--20 invoices per month. Accounting depth is lighter than Wave or QuickBooks. Best fit for the freelance creative professional for whom the invoice is the product.

Xero is the strongest international option -- better multi-currency, stronger bank feed connectivity outside the US and Canada, and a large third-party app marketplace. Pricing is similar to QuickBooks ($15--$78/month). The accountant ecosystem is strongest in New Zealand, Australia, and the UK. US and Canadian SMBs find it less well-supported by local accountants than QBO.

Zoho Books is the strongest value alternative at $0--$200/month. It includes features (project time tracking, client portals, inventory management) that Wave and FreshBooks require add-ons for. The tradeoff is a UI complexity that matches the feature breadth -- it has a learning curve that Wave does not.

A custom build beats all five on three dimensions no off-the-shelf platform addresses: an accounting data model that is native to your operational data (no sync, no integration, no export step), a client-facing experience branded to your firm or product, and a payment processing setup where your negotiated rate applies directly with no platform margin sitting above it.

Where accounting software builds go wrong

The failure mode that causes the most rework is building bank reconciliation before designing the reconciliation state machine. Teams build the Plaid import flow (download transactions, store them in a table) and the reconciliation UI (show unreconciled transactions, let the user match them). This works for the simple case: one transaction exactly matches one invoice payment.

It breaks for the real cases: a client pays three invoices in a single ACH transfer (one bank transaction, three accounting entries); a bank transaction for $1,200 represents an invoice for $1,000 plus a late payment fee of $200 that was never invoiced; a Stripe payout lumps seven individual card payments into one bank deposit. These cases require the reconciliation engine to support many-to-one and one-to-many matching, not just one-to-one. Building that after the one-to-one reconciler is shipped requires rewriting the matching logic and the UI that shows match candidates.

The second failure mode is the Canadian sales tax workaround. Teams ship GST/HST support (the federal rate applied uniformly) and discover in month two that their Canadian clients are in British Columbia (7% PST on top of 5% GST), Saskatchewan (6% PST on top of 5% GST), or Quebec (9.975% QST replacing HST). Each province has a different rate, different registration requirement, and different filing deadline. The fix -- integrating a tax calculation API or building a tax rate table with province-specific rules -- adds 2--4 weeks of work that should have been scoped in week one.

The third failure mode is treating the audit trail as a nice-to-have. A financial platform without an immutable audit log of every change to every journal entry cannot support a tax audit or a client dispute. The IRS and CRA both have the authority to examine books for up to 6 years after the tax year. A platform that cannot produce "who changed this entry, from what value, to what value, and when" is not safe for production use with real client data. Build the audit log schema before writing the first journal entry -- it is one day of schema design and 2--3 days of middleware implementation. Retrofitting it onto an existing accounting engine takes 4--6 weeks.

How RaftLabs fits

We build fintech and accounting SaaS platforms for vertical SaaS founders, bookkeeping firms, and freelance platforms. The double-entry accounting engine, Plaid bank feed integration, reconciliation state machine, and SOC 2 compliance controls are problems we have worked through on previous builds. Canadian multi-rate tax support, PIPEDA data residency, and payroll processing for both US and Canadian tax tables are part of the pattern library we bring to every accounting build in this region.

For an accounting platform build, we work in fixed-price cycles. V1 scope is defined in a two-week scoping engagement: we design the chart of accounts hierarchy, model the journal entry schema, identify which bank connectivity provider fits your user base, and map the compliance requirements that apply to your jurisdiction before writing a line of code. The scoping engagement determines whether the build lands in the $55,000--$90,000 V1 range or whether double-entry reporting and bank reconciliation requirements push it to V2 scope from day one. The number in the proposal is what you pay.

If your payment volume is approaching $400,000/year, if you are building a vertical SaaS that needs accounting as a native feature, or if you run a bookkeeping firm managing 30+ clients who deserve a better experience than separate Wave logins -- a scoping call is the right next step. Tell us your use case, your jurisdiction, and the accounting features that matter most to your users, and we will give you a realistic cost and timeline within two business days.