Cloud accounting or ERP — how the tier is actually decided

Almost every business asks this as a software question, and buys the wrong answer. This article sets out the two constraints that make a system feel too small, the six questions that decide the tier, and an honest account of what a connected application ecosystem can and cannot do.

IN SHORT

Choose by process complexity, not by size. If your finance data can stay inside finance, a cloud ledger is right — bank feeds, document capture, automated invoicing, multi-currency, tax tracking and an application ecosystem for the edges. If answering an ordinary question requires data to cross from payroll, operations or sales into finance, you need one database rather than a better ledger. Transaction volume is the wrong proxy; the number of manual crossings per month is the right one.

SECTION 1

The pattern

The question almost always arrives as a software question. Should we upgrade? What are people using? Somebody at a conference mentioned a system.

It is the wrong framing, and it produces a predictable and expensive mistake. A business feels friction, concludes the accounting package has been outgrown, and buys a larger one. Eighteen months later the close still takes six weeks, the spreadsheets are all still there, and a substantial implementation has been paid for. The package was never the constraint.

There are only two constraints that make a finance system feel too small, and they are entirely different problems requiring entirely different answers.

Transaction volume. There is simply more to process than the current arrangement can absorb. This is a ledger problem and it is solved inside the ledger tier — by automating capture, not by buying a bigger system. A business processing thousands of transactions a month on a modern cloud ledger with connected feeds is not straining; a business processing four hundred by hand is.

Process complexity. The question you need answered requires data that lives in more than one place — what did that job actually cost, which customers are unprofitable after service, what is labour as a share of revenue by department. This is a boundary problem, and no amount of ledger improvement solves it, because the data was never in the ledger to begin with.

THE BOUNDARY TEST — in a normal month, how many times does somebody export, retype or reconcile data between two systems in order to answer a question? Count it for one month. Fewer than about four crossings and you have a ledger business. More than a dozen and you have an operating-system business, whatever your size or turnover.

The corollary surprises people, and it is worth stating plainly. A two-hundred-person distributor running one simple process — buy, hold, sell, collect — may belong comfortably in the ledger tier. An eighteen-person engineering consultancy with timesheets, job costing, three entities and two currencies may belong in the integrated tier. Size correlates loosely with complexity and is therefore used as a proxy for it, but it is a poor one, and choosing on headcount or turnover is the most common route to buying the wrong thing.

SECTION 2

The Caribbean variant

Six regional conditions shift where the line falls, and most of them push it downward — meaning smaller businesses here reach the boundary problem earlier than their counterparts elsewhere.

Multi-entity structures are normal at small scale. Property in one company, trading in another, an operating company for the licence — driven by tax, liability and regulatory considerations rather than by size. A twelve-person business here may have three entities, which is a consolidation problem that a single ledger handles awkwardly at any volume.

Multi-currency at every size. Buy in United States dollars, sell in local currency, bank in both, and occasionally invoice in a third. Where this is handled by spreadsheet revaluation, the business has a boundary crossing every single month before it has done anything else.

Labour-intensive sectors where labour is the margin question. Hospitality, agriculture, security, construction and facilities management all live or die on labour cost per job, per site or per cover. That number requires attendance data to reach the ledger, which is precisely a boundary crossing — and it is the single most common reason a regional business needs the integrated tier.

Import-led trading needs landed costing. Freight, duty, wharfage and clearance allocated across a shipment to arrive at true unit cost. The spreadsheet that does this is the most common bridge in the region, and it is almost always undocumented and personally maintained.

Subscription pricing removed the capital barrier. The integrated tier was historically out of reach for mid-market businesses because it required licences, servers and a capital project. Subscription delivery means the decision is now genuinely about fit rather than about affordability, which is a recent change and not yet widely absorbed.

Implementation capacity is the binding constraint, not licence cost. The regional shortage is of people who can configure, migrate and then operate these platforms properly. A correct tier decision followed by a poor implementation produces a worse outcome than a conservative choice implemented well.

SECTION 3

What it costs

The tier decision can be wrong in both directions, and the two failures look nothing alike. The figures below are indicative, drawn from advisory experience across the region rather than from survey.

Choosing the integrated tier too early. Implementation effort and cost disproportionate to the benefit; modules configured and never used; a close that lengthens rather than shortens while the organisation learns; and change fatigue that makes the next improvement harder to sell internally. A business with four boundary crossings a month does not need one database. It needs connected bank feeds.

Staying in the ledger tier too long. The spreadsheet bridges multiply, one per unanswered question. Each is a manual process, a key-person dependency and a reconciliation. Businesses rarely notice the accumulation, because each individual bridge was a reasonable solution to an immediate problem.

The running cost of the bridges themselves. Where a business maintains five or six regular exports and reconciliations, that is commonly two to four staff days a month spent moving data between systems — work that produces nothing, cannot be reviewed easily, and is the most error-prone activity in the whole function.

Audit cost on bridged data. Where a figure in the accounts originates in a spreadsheet rather than in the ledger, the auditor must test the spreadsheet. That is slower, more expensive, and more likely to produce a control observation than testing a system-generated balance.

Questions that go unanswered entirely. The largest cost and the least visible. Job-level margin, customer profitability after service, labour as a proportion of revenue by site — not answered late, but not answered at all, because producing the answer would take a week and by then it would be a different question.

A spreadsheet bridging two systems is not a workaround. It is an unfunded, undocumented, single-person software product that your business now depends on.

SECTION 4

What the capability actually does

Set out plainly, the two tiers do different things. Neither is an upgrade of the other; they address different constraints.

Tier one — the cloud ledger

For owner-managed and single-process businesses, transaction-led. The capability set:

Direct bank and card feeds with rules-based categorisation
Digital capture of receipts, bills and supporting documents at the point of arrival
Recurring, electronic and automated follow-up invoicing
Multi-currency ledgers with automated revaluation
GCT, VAT and sales-tax tracking and return preparation
Role-based accountant and owner access permissions
Live dashboards for cash, receivables and payables
An open application ecosystem for payroll, point of sale and inventory

Tier two — the integrated business platform

For multi-department, multi-entity and multi-territory organisations, process-led. The capability set:

Finance, HR, payroll, CRM and operations reading from one database
Project, task and job costing linked directly to the ledger
Attendance and biometric time capture flowing into labour cost
Performance and KPI reporting by employee, department and entity
Module-level permissions and full approval workflow
Consolidation across entities, currencies and territories
Mobile access to live data and approvals from any location
Enterprise-grade cloud hosting, backup and access logging

The six questions that decide it

These are the substance of the Finance Function Diagnostic. Each answer points one way or the other, and the pattern across all six is the recommendation.

How many legal entities, currencies and territories report into the group? One entity and one reporting currency sits comfortably in tier one. Three or more entities requiring consolidation, or operations across territories with different statutory bases, points firmly to tier two.

Do finance, payroll and operations need to read from one dataset? If labour cost by job, site or department is a question you need answered monthly, the answer is yes, and this question alone is frequently decisive.

Should approval authority be enforced by the system, or remain informal? Where approvals must be demonstrable to a lender, a regulator or an auditor — or where the business has grown past the point at which the owner sees every transaction — enforced workflow is a tier-two capability.

Is costing needed by job, project, contract or department? Product-level margin is available in tier one. Job, contract and project margin that includes labour and overhead allocation is not, and no ledger will produce it.

How many users require role-restricted access, and to what? A handful of finance users with owner oversight is tier one. Dozens of users across departments, each needing a different slice with different rights, is tier two.

Is the binding constraint transaction volume, or process complexity? The summary question. Volume is solved by automating capture within tier one. Complexity is solved only by removing the boundaries, which is what tier two is.

What the application ecosystem can and cannot do

This deserves stating honestly, because it is where most tier decisions go wrong. A cloud ledger with connected applications is genuinely powerful and covers far more ground than most businesses realise — payroll, point of sale, inventory, expenses, document management, all synchronising on a schedule. For a great many businesses it is the right answer and the integrated tier would be over-engineering.

But connected applications extend a ledger sideways; they do not create a single database. Each connection is a synchronisation with a timing, a mapping and a failure mode. Where the same record must be simultaneously authoritative for two departments — the hour worked that is both a payroll cost and a job cost, the sales order that is both a commitment and a forecast input — an ecosystem is a reconciliation waiting to happen, and the reconciliation will be performed by a person, monthly, forever.

SECTION 5

How the Accounting Services BPO Division delivers it

The six questions are answered with you, before anything is priced. The Diagnostic works through them against your actual processes rather than against a questionnaire, and produces a written recommendation naming the tier and, more importantly, the reasoning. You should be able to disagree with it on the evidence.

Platform-agnostic by policy. Dawgen Global is not a software reseller and receives nothing from a tier-two recommendation that it does not receive from a tier-one one. The recommendation follows the operating model, and where the honest answer is “fix your capture and stay where you are”, that is the answer given.

The team that implements is the team that operates. Configuration decisions are made by people who will live with them monthly. This removes the most common implementation failure, which is a system configured to a specification by somebody who will never run a close on it.

The migration path is preserved deliberately. A tier-one implementation is built so that it can be left — clean master data, documented coding rules, exportable history. Businesses grow into the boundary problem, and the tier-one decision should not become the reason the tier-two move is unaffordable three years later.

Delivery is tier-neutral. The output schedule, the nine-day close, the management pack and the service levels are the same in both tiers. The platform changes what can be asked; it does not change what is promised.

SECTION 6

Where to start

In the next thirty days. Run the boundary test for one month. Every time somebody exports, retypes or reconciles between two systems, add a line: what was moved, from where to where, how long it took, and what question it was answering. Do not estimate this from memory — the count is always higher than anyone expects, and the list is the evidence the decision turns on.

In thirty to ninety days. Fix capture first, whatever the count says. Connected bank feeds, digital document capture and rules-based coding are tier-neutral, they pay for themselves in either direction, and they will not be wasted if you later move. A business that has not automated capture cannot sensibly evaluate whether it needs a bigger system, because it has never seen what its current one can actually do.

Beyond ninety days. Take the tier decision on the count and the six questions, not on turnover, headcount or what a comparable business bought. If the answer is tier one, stop — you have saved a project. If it is tier two, sequence it after capture is working, never alongside.

Most businesses asking whether to upgrade need better capture, not a bigger system. A minority genuinely need one database, and for them no amount of ledger improvement will ever be enough. The entire value of the question is knowing which one you are.

REFERENCE

Frequently asked questions

Cloud accounting or ERP — which do I need?

Decide on process complexity rather than size. If finance data stays within finance, a cloud ledger with connected applications is right. If ordinary questions require data from payroll, operations or sales to reach the ledger, you need one database. Count the manual data crossings in a normal month: fewer than four points to a ledger, more than a dozen points to an integrated platform.

At what size should a business move to an integrated system?

There is no reliable size threshold. A two-hundred-person single-process distributor may belong in the ledger tier; an eighteen-person consultancy with job costing, timesheets and three entities may belong in the integrated tier. Headcount and turnover correlate loosely with complexity and are poor proxies for it.

Can connected apps do what an integrated platform does?

Up to a point, and further than most businesses realise. But applications extend a ledger sideways rather than creating one database. Where a single record must be authoritative for two departments at once — an hour that is both payroll cost and job cost — an ecosystem leaves a monthly reconciliation that a person has to perform.

What does it cost to get the tier decision wrong?

Choosing the integrated tier too early means implementation effort out of proportion to benefit, unused configuration and a close that lengthens while the organisation learns. Staying in the ledger tier too long means accumulating spreadsheet bridges — commonly two to four staff days a month of pure data movement, each bridge a key-person risk.

Do we have to replace our current accounting software?

Often not. If the constraint is transaction volume, automating capture within your existing ledger resolves it. Replacement is warranted when the operating model has outgrown what a ledger can express — multiple entities, job costing, enforced approvals — not because processing is slow.

If we start in the ledger tier, can we move later?

Yes, provided the first implementation is built to be left: clean master data, documented coding rules and exportable history. Businesses grow into the boundary problem regularly, and the tier-one decision should never be the reason a later move becomes unaffordable.

NEXT STEP

Request the Finance Function Diagnostic

A 45-minute scoping conversation covering volumes, systems, entities, close cycle and reporting needs; a written recommendation on tier, scope, division of labour and transition plan; and a fixed-scope service proposal priced by process, with service levels and exit terms stated.

Contact us: Dawgen Global · Accounting Services BPO Division: [email protected] · dawgen.global/contact-us

Continue reading: “What a finance function is supposed to produce, and how often.” · “One login for finance, people and sales is not a convenience. It is a control.” · “The question is not what the platform costs. It is what it replaces.”

Indicative figures are drawn from advisory experience across the region and are not survey output.

About Dawgen Global

Dawgen Global is an independent, integrated multidisciplinary professional services firm headquartered at 47 Trinidad Terrace, New Kingston, Jamaica, serving more than 15 territories across the Caribbean. Founded and led by Dr. Dawkins Brown, Executive Chairman, the firm is independent and not affiliated with any international network. It delivers a full suite of professional services under one roof: audit and assurance; tax advisory; IT and digital transformation; risk management; cybersecurity; actuarial and insurance regulatory advisory; HR advisory; mergers and acquisitions; corporate recovery; business advisory and strategy; accounting BPO and virtual CFO services; and legal process outsourcing.

The proposition is simple: big-firm capability without the big-firm price. Dawgen Global’s integrated approach is built for the specific complexities and opportunities of the Caribbean market, helping organizations make sharper, better-informed decisions that drive measurable progress.

To explore a partnership, reach out: