Multi-business · Africa
Each registered company is a separate legal person with its own tax registrations, its own filings and its own financial statements, so its records have to be separate at the data layer rather than separated by a column or a report filter. One login can hold several businesses; one set of books cannot hold several companies.
Last updated 2026-09-04. Published by Umbra ERP.
A registered company is a separate legal person. It holds its own assets, owes its own debts, registers separately with the revenue authority, files its own returns and produces its own financial statements. Two companies with the same shareholder are not two departments of one business, however similar they look from the inside.
The consequence people underestimate is evidential. Limited liability rests on the separation being real, and the primary evidence of whether it was real is the books. Records that show one company paying another's suppliers from a shared account, with no invoice, no loan agreement and no settlement, are the exact record a creditor or a liquidator reads as proof that the entities were operated as one. The separation is not preserved by intention, it is preserved by bookkeeping.
Tax registrations follow the same logic. In Zimbabwe, compulsory VAT registration is triggered where taxable supplies exceed or are likely to reach US$25,000 or the ZiG equivalent within 12 months, and that test applies to the registered operator. Two companies each turning over US$20,000 are two separate positions, not one that crosses the threshold. Get the attribution of revenue wrong and you have either registered an entity that did not need to, or failed to register one that did.
Employment obligations are also per employer. In South Africa the Skills Development Levy is charged at 1 per cent and an employer is exempt where annual payroll is below R500,000, with the levy paid on the EMP201 within 7 days of the end of the month. UIF is 1 per cent from the employee and 1 per cent from the employer, against a ceiling of R17,712 per month, which caps the employee deduction at R177.12 a month. Every one of those figures is measured against a specific employer, so which company employs whom is a fact with a monetary consequence.
Nobody sets out to blend two companies. It happens through one of three specific mechanisms, and each has a recognisable signature.
The first is the company column. One set of books, one customer list, one ledger, and a field on each transaction saying which business it belongs to. This looks like separation and is not, because the field is optional at the moment of writing. Anything captured in a hurry is untagged, untagged rows are silently excluded from both companies' reports, and the two sets of figures no longer add up to the total. Worse, the separation depends on nobody forgetting, which over a year of daily entries is not a control, it is a hope.
The second is the shared bank account. Two businesses, two sets of books, one account because opening a second was inconvenient. Reconciliation then becomes a manual allocation exercise on every line, and the allocation is done from memory weeks later. Interest, bank charges and any payment that covered both entities have to be split, and the split is a judgement nobody records. The account statement, which is the one document a third party will accept as evidence, shows a single undifferentiated flow.
The third is the most expensive: one entity invoicing on behalf of another. It usually starts because one company has the VAT registration, or the bank details the customer already has on file. The revenue lands in the wrong entity's income, the VAT output is declared under the wrong registration, and the entity that actually performed the work has income with no supporting document. Unwinding it properly requires a real intercompany arrangement, an invoice between the two companies, and an agreed basis, all created after the fact. Doing it once is a correction. Doing it habitually is the pattern that makes the two companies look like one.
In software terms this is a tenancy question, and there is a real difference between systems that scope data and systems that filter it.
Filtering means the records live in one pool and each screen adds a condition to its query. It works until one code path forgets. A report written in a hurry, an export, a search box, a new endpoint added by someone who did not know the rule, and rows from another company appear where they should not. The failure is silent because the extra rows look plausible, and it is discovered by a customer of one business seeing something belonging to another.
Scoping means the business identity is part of the request itself and every query is bound to it, so a query that does not name a business does not run at all. In Umbra the business is carried on a header and every route is scoped to it. Switching between businesses changes the header rather than the session, so you move between companies without logging out, and no screen can be reached in a state where it does not know which company it is looking at.
The practical difference shows up in three places. Customer lists stay disjoint, so the same trading name can exist in two businesses as two records, which is correct because they are two separate commercial relationships with two separate balances. Document numbering stays per business, so each company's invoice sequence is unbroken, which matters when an unexplained gap in a fiscal sequence is exactly the kind of thing a revenue authority asks about. And reports stay honest, because an aggregate query cannot accidentally reach beyond the business it was scoped to.
One account can hold up to 25 businesses, including parent and subsidiary structures, which is enough for a genuine group and deliberately not unlimited. The limit is a useful discipline in itself, discussed further below.
Once the tenancy is right, the question becomes which settings belong to the group and which belong to each company. The answer is that anything with a statutory consequence belongs to the company.
Currency is the first. Each business in Umbra holds its own currency, and that is not a display preference. It determines the currency documents are raised in, what the payroll run produces, and what can be summed. Umbra never adds amounts across currencies, so two businesses reporting in different currencies produce two sets of figures that a person combines deliberately, at a stated rate, on a stated date, rather than a single blended number that means nothing.
Payroll configuration is the second, and it is per business for the good reason that payroll is the most jurisdiction-specific thing a company does. Umbra implements payroll for Zimbabwe and South Africa only. A Zimbabwean company calculates PAYE from the ZIMRA tables, NSSA employee and employer contributions, WCIF, ZIMDEF and the 3 per cent AIDS levy, and produces the P9 employee certificate and the ITF16 employer annual return. A South African company calculates PAYE with the primary rebate, UIF for both sides against the monthly cap, and SDL. For the 2027 tax year, which runs from 1 March 2026 to 28 February 2027, the primary rebate is R17,820 and the tax threshold for a person under 65 is R99,000.
A group operating in both countries therefore runs two payrolls with two different calculations, two different remittance deadlines and two different sets of statutory forms. That is not duplication to be optimised away, it is the actual shape of the obligation. Zimbabwean PAYE is remitted on or before the 10th of the following month, in the currency the earnings were received. South African SDL is paid on the EMP201 within 7 days of month end. Two companies, two clocks.
The constraint worth planning around is that a pay run uses one currency for the whole business. Paying some staff in US dollars and others in local currency inside one run is not supported, so a genuinely split workforce is either two pay runs or, where the split is permanent, two business records with their own configurations.
Group reporting is where badly separated books present the bill, usually at year end when the correction is most expensive.
Intercompany transactions are the classic. If the trading company invoices the services company for R80,000, that amount appears as revenue in one set of accounts and as an expense in the other. Adding both companies' income statements together overstates group revenue by R80,000, because the group has not sold anything to anyone outside itself. Proper consolidation eliminates the transaction on both sides. A simple sum across entities does not, and a spreadsheet that stacks two trial balances will quietly report a group that is larger than it is.
Currency is the second. A consolidated figure across a company reporting in US dollars and one reporting in rand requires a translation with a rate, a source and a date attached, and the result is only meaningful alongside those three attributes. This is the same discipline that applies inside a single company's books, applied one level up. A system that refuses to sum across currencies is protecting you here, even when it feels obstructive.
Receivables ageing is the third, and it is the one that costs cash. A customer who buys from two group companies has two balances. Each company's aged receivables shows only its own, so a customer who is 90 days late with both companies for a modest amount each may not trigger a collections call in either, while the group exposure is twice what anyone is looking at. The fix is a deliberate group view, produced on purpose, rather than an assumption that either entity's report tells the whole story.
Document numbering is the fourth and the easiest to get right at the start and impossible to fix later. Sequences belong to a company. Sharing one sequence across two businesses gives each of them a set of invoice numbers with gaps in it, and a gap in a fiscal sequence is a question you will be asked and will struggle to answer years afterwards.
Because creating another business record is easy, the more common mistake among careful operators is creating too many. A branch becomes a business, then a product line, then a project, and a group of two companies is running as nine tenancies.
The cost of over-splitting is real. Every business is a separate chart of accounts to maintain, separate opening balances, separate reconciliation, and a consolidation exercise at every reporting date that only exists because you created it. Nine tenancies for two legal entities means seven of them produce reports nobody files and work nobody needed to do.
The test is statutory rather than operational. If the thing files its own tax return, holds its own tax registration, has its own bank account, or reports in a different currency, it is a business. If it is a branch, a division, a product line or a project inside one legal entity, it is a dimension inside one set of books, and it should be tracked as a department, a project or an account grouping rather than as a separate tenancy.
The exception worth knowing is the permanently split payroll currency. Because a pay run uses one currency for the whole business, a single legal entity that genuinely pays one group of staff in US dollars and another in local currency on an ongoing basis may be easier to run as two business records than as two pay runs indefinitely. That is an operational judgement, and it is worth taking with your accountant, because the books then have to be recombined for the entity's statutory accounts.
Most of the work is done at setup, and most of the damage is done by shortcuts taken in the first month that nobody revisits.
The measure of whether the separation is real is whether each company could be handed to a different accountant tomorrow and produce a defensible set of accounts without the other's records. If answering a question about one entity requires opening the other, the books are already blended, and the cost of unblending them rises with every month that passes.
Yes. One Umbra login can run up to 25 businesses, including parent and subsidiary structures, and you switch between them with a business header rather than logging out. Each business keeps its own customers, documents, numbering, currency and payroll configuration, and every route is scoped to the business you are working in.
Yes, as two separate businesses. Umbra implements payroll for Zimbabwe and South Africa, and each business holds its own payroll configuration, so the Zimbabwean entity calculates PAYE, NSSA, WCIF, ZIMDEF and the AIDS levy while the South African entity calculates PAYE with the primary rebate, UIF and SDL. They remain two sets of books with two filing calendars.
Registration is per registered operator, so each company is assessed on its own supplies. In Zimbabwe compulsory registration is triggered where taxable supplies exceed or are likely to reach US$25,000 or the ZiG equivalent within 12 months. Two companies below the threshold are two separate positions and are not added together.
Not casually. The revenue lands in the wrong entity, the VAT output is declared under the wrong registration, and the company that did the work has income with no supporting document. If it genuinely has to happen, structure it as a real intercompany arrangement with an invoice between the two companies on an agreed basis.
Usually not. The test is statutory: if it files its own return, holds its own tax registration, has its own bank account or reports in a different currency, it is a business. A branch or product line inside one legal entity is a dimension in one set of books, and splitting it into a second tenancy creates a consolidation problem you invented.
Not as an automatic blended figure, and that is deliberate. A group total requires intercompany transactions to be eliminated and, where currencies differ, a stated translation rate and date. Umbra never sums amounts across currencies, so a consolidated figure is something you produce on purpose with its basis shown rather than something a report guesses at.
Access is granted per business, and because every route is scoped to a business rather than filtered in the interface, a user working in one company is not reading another one. That matters most for outside help: a bookkeeper engaged for the trading company has no route to the property company ledger.
Yes, and it should. Payroll is the most jurisdiction-specific process a company runs, and each business holds its own configuration and its own payroll currency. A pay run uses one currency for the whole business, so a workforce paid in two currencies means two runs, or two business records where the split is permanent.
Regulatory figures on this page are taken from the following primary sources. Tax rates and thresholds change; check the source before relying on a figure.