Why integration depth beats feature count

Integration lists are the least informative part of any accounting product page. A logo means a connection exists. It says nothing about what crosses, how often, or how much work remains afterwards.

The difference between a shallow and a deep integration with the same system is larger than the difference between most products' feature sets.

The four depths

Same platform, same logo, four genuinely different things.

Depth 1: totals. A daily or monthly summary figure posts to the ledger. Revenue appears. Nothing else does. You know what you sold in aggregate and nothing about composition, and every reconciliation question requires the platform's own reports.

Depth 2: transactions. Individual orders come across. You can now analyse by product and customer. Fees are still a single net deduction, so you cannot see what anything cost you.

Depth 3: transactions with itemised fees. Orders arrive with commission, transaction fee, shipping subsidy and promotional cost as separate lines. Now per-order profitability is real, and a deduction can be questioned because you can see it.

Depth 4: reconciled to payout. Everything above, plus settlement matched to the orders it covers and the payout matched to the bank, with every line accounted for. This is where you find out whether you were paid what you were owed.

All four say "integrates with" on a website. Only the fourth removes the work.

What to ask instead of checking the list

Four questions per integration that matters:

"What crosses — totals, transactions, or transactions with itemised fees?"

"How often, and is it push or pull?" A nightly automatic sync is different from an on-demand export somebody has to remember.

"Can I reconcile the payout to the orders through your system, or do I export and do it myself?" This is the question. Most integrations stop before it.

"What happens when their API changes?" Who notices, how quickly, and what happens to your data meanwhile.

Why depth matters more than breadth

A business connects to three or four systems that matter: the bank, the sales channels, sometimes payroll or a till.

A shallow integration with all of them leaves you doing reconciliation in a spreadsheet. Data arrives in the ledger, and the actual work — matching, explaining, accounting for every line — remains manual.

A deep integration with the three that matter removes the work. The other fifty logos on the page are irrelevant, because you do not use those systems.

Breadth is a marketing asset. Depth is what changes your week.

The specific test

Take your most important integration and ask for a demonstration of one complete cycle:

Order placed → order in the ledger → fees itemised → settlement received → settlement reconciled to the orders → payout matched to the bank statement.

A deep integration shows the whole chain. A shallow one shows the first step and then describes a report you would export.

Watch specifically for where the chain breaks, because that break is where your manual work will be — permanently.

The half-integration to watch for

A common pattern worth recognising: data comes in properly, and nothing goes back out.

Orders arrive with full detail. But when you issue a credit note, adjust a price or resolve a dispute, that has to be entered separately in the platform. The integration is one-directional, and the two systems drift.

Ask about both directions. The inbound one is usually demonstrated and the outbound one usually is not.

What a missing integration actually costs

Less than assumed, which is worth knowing before ruling a product out.

A scheduled file export processed automatically achieves most of what an API does. The difference matters far less than vendors imply, and a deep file-based integration beats a shallow API one comfortably.

So the question is not "do you integrate with X" but "what crosses, how often, and does the reconciliation complete". A product that reconciles fully via a nightly file is a better answer than one with a real-time API delivering totals. See when your other systems are the constraint.

Common questions

What makes one integration better than another?

Depth of what crosses. The same logo can mean daily totals posting to the ledger, individual transactions, transactions with itemised fees, or a full chain where settlements reconcile to orders and payouts match the bank. Only the last removes the manual work, and all four appear identically on a product page.

What should I ask about an integration?

What crosses — totals, transactions, or transactions with fees itemised separately; how often, and whether the sync is automatic or requires someone to trigger it; whether the payout can be reconciled to the orders inside the system or requires exporting and doing it yourself; and what happens when the other platform changes its interface.

Is a missing API a dealbreaker?

Usually not. A scheduled file export processed automatically achieves most of what an API does, and a deep file-based integration is considerably better than a shallow API that delivers only totals. The right question is what crosses and whether the reconciliation completes, rather than whether a particular connection method is used.

What is a half-integration?

One where data flows inbound with full detail but nothing flows back. Orders arrive properly, while credit notes, price adjustments and dispute resolutions have to be entered separately in the other platform, so the two systems gradually drift apart. The inbound direction is usually demonstrated and the outbound one usually is not, so it is worth asking about both.

Related: connecting sales channels to your ledger · when your other systems are the constraint · how to evaluate AI accounting software