If you are building software that touches accounting data, you need to understand the difference between accrual and cash-based accounting. The accounting method your customer uses changes what the numbers in their ledger actually mean.

And it gets more complex when you operate across borders. The rules are not the same in the US, the UK, and Europe. The thresholds differ. The defaults differ. What is mandatory for a company in Germany may be optional for the same size company in Texas.

This post covers the fundamentals first, then the geographic nuances, then what all of this means when you are building accounting integrations through APIs.

Part 1: The Fundamentals

Cash-based accounting

Cash-based accounting records transactions when money moves. Revenue is recognized when payment hits your bank account. Expenses are recorded when the payment leaves. Simple. Predictable. Easy to reconcile against your bank statement.

A freelancer sends an invoice in March. The client pays in May. Under cash-based accounting, that revenue shows up in May. There is no accounts receivable entry. There is no accrual adjustment at year end.

This method works well for sole traders, small service businesses, and anyone who primarily deals in straightforward cash transactions. It gives you an accurate view of how much money is actually available right now.

The downside is that it can distort the picture of how a business is performing. Revenue earned in one period may show up in another. A business can look profitable in one quarter simply because a batch of invoices happened to get paid, while the next quarter looks terrible because nothing came in.

Accrual-based accounting

Accrual accounting records transactions when they are earned or incurred, regardless of when cash changes hands. Revenue is recognized when a sale is made. Expenses are recorded when the obligation is created. This is the matching principle in action: match revenue with the costs required to generate it.

Same example. Freelancer sends an invoice in March. Under accrual accounting, the revenue is recorded in March, even if the payment does not arrive until May. There is an accounts receivable entry on the balance sheet until the cash comes in.

This method gives a more accurate picture of a company's financial health over time. It is why both GAAP (Generally Accepted Accounting Principles, used in the US) and IFRS (International Financial Reporting Standards, used in most of the rest of the world) require accrual accounting for financial reporting.

The trade-off is complexity. You need to track receivables, payables, accrued expenses, prepayments, and deferred revenue. Closing the books at period end takes more work. You need to estimate some amounts that are not yet final.

Why it matters for software

If your application reads financial data from an accounting system, the accounting method determines what those numbers mean. A Profit & Loss report pulled from a cash-basis ledger will show different revenue figures than the same report pulled on an accrual basis, even for the same business in the same period.

If you are building lending software, expense management, or financial analytics, you need to know which basis you are working with. Otherwise your risk models, forecasts, and dashboards are built on assumptions that may not hold.

Part 2: Geographic Differences

The rules around which businesses must use accrual accounting, which can choose, and which default to cash vary significantly across markets.

United States

The US is relatively permissive. The IRS allows most small businesses to use the cash method as long as they meet the gross receipts test. Since the Tax Cuts and Jobs Act (TCJA), the threshold has been indexed for inflation. For tax years beginning in 2025, the threshold sits at $31 million in average annual gross receipts over the prior three-year period.

Below that threshold, sole proprietors, S corporations, partnerships without C corporation partners, and qualified personal service corporations can all use cash-basis accounting. C corporations and partnerships with C corporation partners must use accrual if they exceed the threshold.

There are additional nuances around inventory. Businesses that produce, purchase, or sell merchandise generally need to use accrual for inventory accounting. But the small business taxpayer exception lets qualifying businesses treat inventory as non-incidental supplies and stay on cash.

The practical result: a large portion of US small and mid-market businesses use cash-basis accounting. QuickBooks holds roughly 80% market share among US small businesses by most estimates, and many of those customers run on a cash basis.

United Kingdom

The UK took a dramatic step in April 2024. HMRC made cash-basis accounting the default method for sole traders and partnerships. Previously, cash basis was opt-in with a turnover threshold of £150,000 to enter and £300,000 to stay. Those thresholds have been completely removed.

Now, any sole trader or eligible partnership in the UK automatically uses cash-basis accounting unless they actively opt out and choose traditional (accrual) accounting on their Self Assessment tax return. This is a deliberate simplification move, aligned with HMRC's Making Tax Digital initiative.

Limited companies and LLPs cannot use cash basis. They must use accrual accounting and comply with UK GAAP or IFRS. But for the vast majority of UK self-employed individuals, cash is the default.

This means if you are building software for UK SMBs and sole traders, the most common scenario is cash-basis data flowing through the system. Xero, FreeAgent, and other UK-popular platforms all support cash-basis reporting.

Europe (EU and EEA)

Europe is more fragmented. Each EU member state has its own rules, but the EU Accounting Directive provides a framework with simplified reporting regimes for SMEs and micro-businesses.

Germany is strict on income tax accounting. The mandatory double-entry bookkeeping threshold under §141 AO applies at €800,000 in revenue or €80,000 in profit per year. These thresholds were raised from €600,000 and €60,000 respectively by Germany's Growth Opportunities Act (Wachstumschancengesetz), which came into force in March 2024. Sole proprietors and civil law companies (GbRs) below that threshold can use a simplified income-expenditure method (EÜR). Companies required to keep books, such as a GmbH, OHG, or UG, can apply for cash-based VAT treatment (Istversteuerung under §20 UStG) if their annual revenue is below €800,000. This threshold was also raised from €600,000 in January 2024. For income tax and statutory reporting purposes, most German businesses of any meaningful size use accrual accounting.

The Netherlands allows businesses to opt for cash accounting for VAT purposes. The rules depend on entity type and turnover levels. But for corporate income tax and statutory reporting, accrual is standard.

France similarly requires accrual accounting for most businesses that are under a real tax regime (régime réel). Simplified cash-like reporting is available for micro-enterprises below certain thresholds, but the default for any established business is accrual.

The broader pattern in Europe: accrual is the default for any company required to file statutory accounts. IFRS applies to listed companies. National GAAP (which is generally aligned with or derived from the EU Accounting Directive) applies to most others. Cash accounting is an exception for the smallest businesses, not the norm.

From a VAT perspective, the EU SME scheme caps the threshold at €85,000 for domestic VAT exemption and €100,000 for the cross-border scheme. These thresholds took effect from January 2025 under EU Council Directive 2020/285. They overlap in practice with the cash accounting question because the businesses small enough to qualify for VAT simplification are often the same ones that might use cash accounting.

Australia and New Zealand

Australia allows small businesses with an aggregated turnover under AUD 10 million to use cash accounting for GST purposes. Above that threshold, the non-cash (accruals) method is mandatory. For income tax, both cash and accrual methods are available to eligible businesses, though accrual remains the norm for companies required to prepare statutory financial statements under Australian Accounting Standards. New Zealand follows a similar pattern. Xero was built in New Zealand and its defaults and data models reflect this accrual-first environment.

What this means in practice

If you are building a multi-market product that touches accounting data, you cannot assume a single accounting method across your customer base. US customers are more likely to be on cash basis. UK sole traders default to cash. European and ANZ customers are more likely to be on accrual. And even within a single market, the accounting method can vary by entity type and size.

Part 3: What This Means for Your API Integration

The problem for developers

When you connect to an accounting platform through its API, the data you get back is shaped by the accounting method the business uses. This creates several concrete challenges.

Profit & Loss reports. QuickBooks Online lets you pull P&L reports on either a cash or accrual basis through its API, regardless of the company's default setting. Xero defaults to accrual and lets you switch in connected tools. Sage simply returns data in whatever method the business has configured. If your application does not account for this, you may be comparing cash-basis P&L data from one customer with accrual-basis data from another.

Revenue recognition timing. On an accrual basis, revenue shows up when an invoice is created. On a cash basis, it shows up when the payment is received. If you are building a lending product that assesses revenue trends, mixing these two data sets without normalization will produce unreliable results.

Accounts receivable and accounts payable. Under cash-basis accounting, AR and AP effectively do not exist in a meaningful sense. The ledger does not track outstanding invoices as balance sheet items. If your application expects to pull AR aging data to assess credit risk, that data may be empty or absent for a cash-basis customer.

Balance sheet completeness. A cash-basis balance sheet is incomplete by definition. There are no accrued expenses, no deferred revenue, no prepayments. If your product needs a full picture of a company's financial position, you need accrual data.

How accounting APIs handle this

Each accounting platform handles the cash vs accrual distinction differently at the API level.

QuickBooks Online stores all transaction data and can generate reports on either basis. The QBO Reports API accepts an accounting_method parameter that can be set to Cash or Accrual. This is powerful because it means you can always request accrual-basis reports even if the company's default is cash. The underlying journal entries contain enough data to reconstruct either view.

GET /v3/company/{companyId}/reports/ProfitAndLoss
  ?accounting_method=Accrual
  &start_date=2025-01-01
  &end_date=2025-03-31

Xero defaults to accrual and stores transactions accordingly. When you pull reports through the Xero API, the default is accrual. Cash-basis reporting is handled by connected tools (like Fathom) that can reprocess the data. The API itself returns accrual-basis data. Invoice objects include status fields like AUTHORISED, PAID, and VOIDED that let you reconstruct cash-basis timing if needed.

Sage Business Cloud returns data based on the company's configuration. The API does not offer a toggle to switch between cash and accrual views. What you see is what the business has set up. If they run on cash, you get cash-basis data.

NetSuite is accrual-first by design. As an enterprise ERP, it assumes accrual accounting. Revenue recognition schedules, multi-period allocations, and deferred revenue are all built into the data model. Cash-basis views are available through reporting configurations but the transaction data is fundamentally accrual.

Building for both: the unified API approach

When you are integrating with multiple accounting platforms across multiple markets, the challenge compounds. You are dealing with different APIs, different data models, different authentication methods, and different assumptions about accounting basis.

A unified accounting API normalizes these differences. Instead of writing separate integration code for QuickBooks, Xero, Sage, and others, you connect once and get a standardized data model across all platforms.

For the cash vs accrual problem specifically, a unified API can:

• Expose the accounting method as a field on the company or organization object, so your application knows what basis the data represents
• Normalize invoice objects to include both the invoice date (accrual timing) and payment date (cash timing), giving you the data to reason about either method
• Standardize balance sheet accounts across platforms so your code does not need to handle the differences between how QBO, Xero, and Sage represent AR and AP

Here is an example using Apideck's Accounting API to pull invoices with both timing signals:

import { Apideck } from '@apideck/node'

const apideck = new Apideck({
  apiKey: process.env.APIDECK_API_KEY,
  appId: process.env.APIDECK_APP_ID,
  consumerId: 'customer-123'
})

// Pull invoices with both accrual and cash timing data
const { data: invoices } = await apideck.accounting.invoicesAll({
  filter: {
    updated_since: '2025-01-01T00:00:00.000Z'
  }
})

// Each invoice includes:
// - invoice_date (when it was issued, accrual timing)
// - due_date (when payment is expected)
// - paid_date (when payment was received, cash timing)
// - status (DRAFT, AUTHORISED, PAID, VOIDED)
// - balance (outstanding amount)

for (const invoice of invoices) {
  console.log(`Invoice ${invoice.number}`)
  console.log(`  Issued: ${invoice.invoice_date}`)    // accrual
  console.log(`  Paid:   ${invoice.paid_date}`)        // cash
  console.log(`  Status: ${invoice.status}`)
  console.log(`  Balance: ${invoice.balance}`)
}

This gives you the building blocks to handle both accounting methods in your application logic, regardless of which platform the customer uses.

Handling multi-market scenarios

If your product serves customers in the US, UK, and Europe, here are the practical patterns to follow.

Detect the accounting method. Always check the organization's accounting method configuration when a new customer connects. Do not assume. Store this alongside the connection metadata so your application logic can branch accordingly.

Normalize revenue data. For analytics and reporting, decide whether your product works on a cash or accrual basis internally. Then normalize incoming data to match. If you need accrual-basis revenue but the customer runs on cash, you can often reconstruct accrual timing from invoice dates. The reverse (deriving cash from accrual) requires payment data, which most APIs expose.

Handle missing data gracefully. Cash-basis customers may have sparse or empty AR/AP data. Your UI and logic need to handle this without breaking. Do not show an AR aging chart that is empty and confusing. Instead, adapt the experience based on the accounting method.

Be explicit about basis in reports. If your product generates financial reports or exports data, always label the accounting method. A revenue chart that does not specify cash vs accrual is a chart that can be misread.

Tax implications vary by region. If your product handles anything tax-related, be aware that the accounting method for tax purposes may differ from the method used for management reporting. A UK limited company must use accrual for statutory accounts but might use simplified reporting internally. A US business might use cash for tax but accrual for management purposes. The API data reflects the accounting system's configuration, not necessarily the tax reporting basis.

The trial balance: where it all comes together

The trial balance is the foundational report for any accounting integration. It is a list of all accounts with their debit and credit balances at a point in time. On an accrual basis, the trial balance includes accrued income, accrued expenses, prepayments, and deferred revenue. On a cash basis, many of these accounts either do not exist or carry zero balances.

If your product relies on the trial balance for financial analysis, credit assessment, or automated bookkeeping, you need to understand which version you are looking at. A cash-basis trial balance can look very different from an accrual-basis trial balance for the same business in the same period.

For platforms like QuickBooks that support both views, you can request the trial balance on either basis. For platforms that only return data in the configured method, you need to work with what you get or build conversion logic in your application layer.

Part 4: Platform Support Reference

The table below covers the full range of accounting systems and ERPs you are likely to encounter when building for US, UK, European, and ANZ markets. Cash basis column indicates whether the platform supports it at all; API basis toggle indicates whether you can request a specific basis via API parameter rather than relying on the company's configuration.

Platform	Cash basis	Accrual basis	API basis toggle	Default	Primary markets
QuickBooks Online	Yes	Yes	Yes (accounting_method param)	Varies (cash common for US SMBs)	US, CA, UK, AU
QuickBooks Desktop	Yes	Yes	No	Set per company	US, CA
Xero	Reports only	Yes	No	Accrual	AU, NZ, UK
Sage Business Cloud	Config-dependent	Yes	No	Accrual	UK, IE, US
Sage Intacct	Reports only	Yes	No	Accrual	US enterprise
Sage 50	Yes	Yes	No	Set per company	UK, US, CA
NetSuite	Reports only	Yes	Via SuiteQL	Accrual	Enterprise global
MS Dynamics 365 BC	Reports only	Yes	No	Accrual	Enterprise global
SAP Business One	No	Yes	No	Accrual	Mid-market global
FreshBooks	Yes	Yes	No	Set per account	US, CA
Wave	Yes	Yes	No	Accrual	US, CA
Zoho Books	Yes	Yes	Report params only	Accrual	Global SMB
FreeAgent	Yes	Yes	No	Cash (sole traders)	UK
Exact Online	No	Yes	No	Accrual	NL, BE, EU
Moneybird	Yes	Yes	No	Accrual	NL
Yuki	No	Yes	No	Accrual	BE, NL
Odoo	Via journal config	Yes	No	Accrual	Global

QuickBooks Online is the only platform here that offers a genuine API-level basis toggle. You can request either cash or accrual regardless of how the company is configured. That makes it the most flexible platform for products that need to normalize data across a mixed customer base.

Most other platforms return data in whatever basis the company has configured and offer no server-side switch. If you need cash-basis data from a Xero customer, you reconstruct it from payment dates on the invoice objects. If you need accrual from a Sage Business Cloud customer running on cash, that conversion happens in your code.

Exact Online, Yuki, and SAP Business One are accrual-only. If you are building for Benelux or mid-market European buyers, assume accrual. There is no cash-basis configuration in these systems.

FreeAgent is the UK outlier. It defaults to cash basis for sole traders, in line with HMRC's April 2024 change. If you are seeing sparse AR and AP data from UK FreeAgent connections, check whether the customer is a sole trader on cash before assuming a data issue.

Deferred revenue and what it exposes about platform differences

Deferred revenue is a good test case for how much any given platform understands about accrual accounting. It is a current liability: cash has been received, but the obligation to deliver the service or product has not yet been fulfilled. A SaaS company that collects $12,000 for an annual subscription on January 1 records $12,000 in deferred revenue on that date, then recognizes $1,000 per month as the subscription period passes. On a cash basis, none of that exists. The $12,000 shows up as revenue in January.

The gap this creates for developers is concrete. If you pull P&L data from a SaaS company on cash-basis accounting, their January looks exceptional and the rest of the year looks flat. If you pull from the same company on accrual, you see $1,000 per month throughout the year. These are not just different accounting treatments of the same underlying reality. They tell completely different stories about the business.

NetSuite has the most complete implementation of any platform in common use. Revenue recognition is a core module, not a bolted-on feature. You can pull recognition schedules directly from the API, query deferred revenue balances by contract or item, and get forecast data showing how deferred amounts will recognize over future periods. Sage Intacct also has dedicated revenue recognition, with contract-level schedules and multi-element arrangements exposed through the revenue management objects.

QuickBooks Online supports deferred revenue in the sense that you can create a liability account and manually post journal entries against it. But there is no native recognition scheduling. You cannot query how much of a company's deferred revenue will recognize in Q3 through the QBO API. You get the account balance; the schedule lives in a spreadsheet.

Xero has no native deferred revenue module. Teams handle it through manual journal entries or third-party tools. What you get from the Xero API is the balance in whatever liability account the accountant set up. There is no structured recognition data behind it.

FreshBooks and Wave have no deferred revenue support. They are built for service businesses billing hourly or per project, where the concept rarely applies.

Whether structured recognition schedules exist depends on the platform, not the business. NetSuite and Sage Intacct expose them via API. QBO, Xero, and most SMB platforms do not. If you need scheduled data, you either connect at the ERP layer or build your own estimation logic from invoice and contract data.

A deferred revenue balance on the balance sheet is also not always reliable as a standalone metric. For QBO customers, it often reflects manually created journal entries rather than a systematically maintained schedule. The number may be accurate or it may be months stale. Before using it in credit assessment or financial modeling, treat it as a starting point.

Zero deferred revenue in the ledger does not necessarily mean the business has none. For cash-basis customers, it simply does not appear. The information is absent by design, not because the business has no advance payments.

What to do about it

If you are building a product that connects to accounting platforms, treat the accounting method as a first-class concept in your data model. Detect it early. Handle both methods in your logic. Label your outputs clearly so nobody misreads a cash-basis revenue number as accrual.

The businesses connecting to your product have no choice in the matter. Their accounting method is determined by their jurisdiction, their entity type, and their size. Your job is to meet them where they are and make the data useful regardless.