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 has roughly 80% market share among US small businesses, and many of those QuickBooks 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 €600,000 in revenue or €60,000 in profit per year. 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 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 are separate from the accounting method question, but they overlap in practice 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.

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.