One Truck, Four Assets
Operations registers the truck once: one code, one barcode, one custodian. Your expert-comptable registers it as four things with four different lives. Both are correct, they are counting different objects, and the trouble starts the day you replace the engine.
A tipper truck is delivered. The workshop registers it the way any operations team would — one asset, one code, one barcode, one custodian, one purchase cost. The expert-comptable opens the same invoice and does something that looks perverse from the yard: they write down four things. A chassis with one life, an engine with a shorter one, a set of tyres with a much shorter one, and a body. Four amortisation schedules for a vehicle that has one number plate and one driver.
Neither party has made a mistake. They are answering different questions about the same steel, and the answers legitimately have different shapes. What nobody notices is that this is not a labelling disagreement that a shared spreadsheet resolves — it is a disagreement about how many rows there should be, and that is the one kind of mismatch a register cannot absorb quietly.
Two things the harmonised plan does that a local category list does not
If you have worked in a market where the chart of accounts is a matter of professional judgement, the usual advice on asset categories is to agree a sensible list with your accountant before anybody starts typing. That advice is correct almost everywhere and it is mildly misleading here, for two separate reasons.
The first is that you do not choose the classes. The harmonised system prescribes the plan: class 2 holds the immobilisations, subdivided by nature — intangibles, land, buildings and fittings, plant and equipment including transport — with class 28 carrying the accumulated amortisation against them. The names and the numbers are given to you. Your category list is not a naming convention your organisation agrees on; it is an answer sheet you are copying from, and getting it wrong is not untidiness, it is a mapping error somebody has to unpick at close.
The second is the one this post is actually about. Under the revised system, a significant item whose parts have materially different useful lives is accounted for by component. Each significant part carries its own value and its own life and is amortised separately. This is settled, internationally aligned treatment, and it has a consequence that everybody discovers late: the accounting object is no longer the machine.
What the register actually holds, on the classification question
The general boundary here — that this is a custody register which feeds a depreciation schedule rather than producing one — is set out in full in asset register versus depreciation ledger, and everything in it applies. There is no method, no useful life, no residual value, no accumulated amortisation and no carrying amount on an asset. Assume that argument rather than repeating it.
What matters for this post is narrower and easy to miss. Category is a free-text label — a string of up to 120 characters, indexed for filtering, with nothing behind it. There is no account-code column on an asset and no link of any kind to a chart of accounts. Nothing validates what you type, nothing warns you that two people have entered "Matériel de transport" and "Materiel de Transport", and nothing will ever tell you that a category you invented has no home in the plan.
Read as a complaint, that is unfair — a general-purpose register that hard-coded one country's chart of accounts would be worse, not better. Read as a design instruction, it is useful, and the instruction is short: because nothing constrains the field, the constraint has to be yours, and it has to be applied at the moment of registration rather than discovered at close.
The field will accept anything. That is precisely why the value you put in it should be the account label from the plan, agreed once, typed the same way every time — because the register will not be the thing that catches it.
The granularity problem, worked
Here is where the shapes genuinely diverge. Illustrative figures, in CFA francs, for one heavy vehicle.
One purchase, four amortisation schedules
The figures are illustrative and the split is not something a blog post can give you. It comes from the supplier's breakdown on the invoice where one exists, and from your expert-comptable where one does not, and which components are significant enough to separate is a judgement made per class of asset and not per truck.
On day one this costs you nothing. The totals agree, the schedule sits in a workpaper, and the register does its job of telling you where the truck is and who signed for it. The divergence is dormant, and it stays dormant for exactly as long as the machine stays as it was delivered.
The day it bites: replacing the engine
Under component accounting, fitting a replacement engine is a two-part transaction. The remaining value of the old engine is taken out of the books — the component is derecognised, and whatever is left of it goes through the income statement. The new engine is capitalised as a new component with a new life, starting now. It is a disposal and an acquisition happening inside a vehicle that never stopped being the same vehicle.
Now look at what the operations record does on that same day, precisely. The truck is sent to maintenance and returns from maintenance. Those are two of the twelve movement actions an asset can record, and neither of them is about a part. The asset's purchase cost is unchanged. Its purchase date is unchanged — the register still believes every part of this machine is as old as the chassis. And the movement trail, which is genuinely good at custody, has no vocabulary for what happened, because it was built to answer where is it and who has it and this is not that question.
The obvious escape hatch does not work either, and it is worth knowing why before you try it. If the replacement engine is drawn from your own stock, the conversion of stock into an asset always creates a new asset record — it builds a fresh row from the payload, with its own asset code and its own barcode. There is no path in the system that adds cost to a machine that already exists. So the engine either becomes a standalone asset floating in your register with no stated relationship to the truck it is bolted into, or it is consumed as a part and the truck's recorded cost never moves. Those are the two available outcomes. Neither is component accounting.
The failure is silent, and it compounds
Nothing errors. The register stays internally consistent and the schedule stays internally consistent, and they drift apart one repair at a time. It surfaces years later at a physical verification, when the count of machines is right, the total cost is right, and no line in the schedule can be traced to a specific object in the yard — which is the exact condition an auditor is testing for, and the exact condition that takes weeks to unwind.
So decide the granularity deliberately, once
There are two coherent answers and one incoherent one. The incoherent answer is the default: register machines as machines, let the accountant split them in a workpaper, and never write down which register row corresponds to which schedule lines. Pick one of the other two instead, and write the choice down.
Right for most organisations
One asset per machine, with the component split held in the schedule and a stated link
The register stays a custody register and keeps working the way the yard expects. What you add is the link: a custom field on the asset carrying the account label from the plan, and a discipline that every component-level event — a replacement, a major overhaul — is written into the asset's notes on the day it happens, with the amount. That note is what your accountant reads at close, and it is the difference between a five-minute conversation and an investigation.
Right when components are large, tracked and moved independently
Register significant components as their own assets
A generator set on a skid, a crane attachment, a container-mounted plant module — things that genuinely move on their own and get fitted to different parent machines — belong in the register as themselves. Use a custom field to name the parent, because there is no parent relationship to use. Accept the consequences: your asset count is no longer a machine count, moving the parent does not move the child, and physical verification has to know which rows it expects to find inside other rows.
Right for nobody, and extremely common
Split some machines and not others, on no stated rule
This is what happens when the decision is never made explicitly — one workshop registers the generator separately because it arrived separately, another does not. Two years on, nobody can say whether the register holds 400 machines or 400 rows, and the reconciliation to the schedule becomes archaeology. If you take nothing else from this post: pick a rule, write it down, and apply it to the class rather than to the item.
The practical setup, which is smaller than it sounds
The good news is that the reporting side of this genuinely works, and it works because of one specific piece of configuration rather than a promise: in the assets report dataset, category is available as a grouping dimension and total purchase cost as a measure. That combination is the whole thing. Group by category, sum cost, filter on purchase date for the period, export.
-
Agree the category values against the plan, with your expert-comptable, in writing
Not "vehicles" and "machines" — the account labels from class 2 as they will appear in your accounts. Agree the spelling and the accents too, because the field is free text and two spellings become two categories in every report you run for the next decade.
-
Add an account-code custom field on assets if your plan is subdivided finely
Custom fields on assets reach the reports surface, so a code field is filterable and exportable rather than decorative. Use it where the category label alone would not tell your accountant which account a purchase belongs in.
-
Write down the component rule per class, not per item
Heavy vehicles: one asset, components in the schedule. Generator sets: separate assets. Whatever you decide — the rule belongs on paper, applied to the class, and the register is not the place it lives.
-
Set the currency on every asset
The register holds a currency per asset, and CFA francs are handled correctly as a currency with no decimal subdivision — amounts are not carrying phantom centimes. Where machines were bought in euros and are held in francs, the currency field is what stops the two being silently added together.
-
Use the notes field as the component log, and make it a step in the repair process
Every replacement, every major overhaul: date, part, amount. It costs thirty seconds and it is the only place in the system that will hold this, because the movement trail records custody events and a component swap is not one.
-
Export additions and disposals at each close
A filter on purchase date and a filter on retirement date, grouped by category. Two exports, and it is the entire operations-to-accounts handover for fixed assets.
What AWRA OpsHub does today
- A category per asset, indexed and filterable, and available as a grouping dimension in reports.
- Total and average purchase cost as report measures, so cost by class is a real exportable report in csv or pdf.
- Custom fields on assets across web, api, mobile, reports, exports, imports and workflows — which is how an account code becomes a reportable field.
- A currency per asset, with CFA francs correctly treated as a zero-decimal currency rather than forced into centimes.
- Ownership type — owned, leased or borrowed — so a hired machine is distinguishable from one you capitalise.
- Purchase date, purchase cost and a properly recorded retirement with date, reason and named person: the inputs a schedule needs and the events it must be told about.
- Documents attached to the asset itself, so an invoice supporting a capitalisation is retrievable years later.
What it does not do
- No chart of accounts for fixed assets, and no account code field as standard. Category is free text with nothing behind it.
- No component or parent-child relationship between assets. There is no such column, so a component registered separately has no stated link to its parent except one you write into a custom field.
- No component-level events. The twelve movement actions cover custody, maintenance, loss, damage, retirement and verification. A part being replaced is not among them.
- No path that adds cost to an existing asset. Converting stock creates a new asset record; it never increases the cost of the machine the part went into.
- No amortisation of any kind — no method, life, residual value, accumulated amortisation or carrying amount, and nothing posts a charge.
- No statutory presentation. We do not produce financial statements in the mandated structure, for assets or anything else.
The first two lines of the right-hand column are the ones that matter for this post, and they are a genuine architectural position rather than an oversight: a register that modelled components would be a heavier thing to operate, and most organisations do not need it. The cost of that position is that the mapping between your rows and your accountant's rows has to be maintained by a person. Knowing that on day one costs you a paragraph of documentation. Discovering it in year three costs considerably more.
What is not built for Senegal today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Senegal. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If DGID declarations, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
DGID declarations and e-invoicing
Declaration output in the format the administration expects and electronic invoicing against any prescribed interface, with retries, a failure queue and a reconciliation report.
Wave, Orange Money and bank feeds
Mobile money settlement files and bank statement feeds pulled into the Payments Register, so collections match invoices without anyone re-keying a statement.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
IR, IPRES and CSS schedules produced in the layout your filing body expects, generated from live payroll records rather than rebuilt in a spreadsheet each month.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedWhere this sits in the larger picture
The division of labour between a statutory ledger and an operations system across these markets is set out in OHADA, SYSCOHADA and your operations system, and this post is one specific seam in that division. The methods themselves — straight-line against reducing balance, and what each does to a charge — are in depreciation methods explained. If your components arrive through your own stores rather than straight from a supplier, the mechanics of turning stock into an asset are in stock to asset conversion, and the multi-currency position across the franc zone is in operating across XOF and the euro.
Our take
Under the harmonised plan two assumptions that hold almost everywhere else stop holding: you do not choose your asset classes, and one machine is not necessarily one depreciable object. The register handles the first with a free-text category that constrains nothing — so put the account label from the plan in it, agreed once with your expert-comptable and typed identically every time, because category is a report dimension and total purchase cost is a measure, which makes cost-by-class a real export rather than a promise. The second is architectural and will not be handled: there is no component relationship on an asset, no movement action for a part being replaced, and no code path that adds cost to a machine that already exists. Choose your granularity per class of asset, write the rule down, log component events in the asset notes on the day they happen, and hand your accountant additions and disposals by category at each close. The failure mode here is not an error message — it is two documents that stay individually consistent and quietly stop describing the same objects.
A register your expert-comptable can reconcile to
Category, purchase date, cost and currency per asset, custom fields that reach reports and exports, retirement with date, reason and named person, and assets as a reportable dataset grouped by class — so the additions-by-account extract is a filter rather than a fortnight.
See plans & pricingFrequently asked questions
Can we hold assets by component in the register?
Not as components of a parent, no. There is no parent-and-child relationship between assets and no column for one — every asset is an independent row. You have two options: register the machine as one asset and keep the component split in your depreciation schedule, or register significant components as separate assets and name the parent in a custom field. The first is right for most organisations; the second is right when the component genuinely moves on its own and gets fitted to different machines.
What happens in the register when we replace an engine?
The truck is sent to maintenance and returns from maintenance. That is all — those are two of the twelve movement actions available, and none of the twelve records a part being replaced. The asset's purchase cost and purchase date do not change, so the register continues to treat the whole machine as the age of its chassis. Record the replacement date, part and amount in the asset's notes on the day it happens; that note is the only place the system will hold it and it is what your accountant needs at close.
If we take the replacement part out of our own stock, does it add to the truck's cost?
No. Converting stock into an asset always creates a new asset record from scratch, with its own code and barcode — there is no code path anywhere that increases the cost of an asset that already exists. So the part either becomes a standalone asset in the register with no stated link to the machine it is fitted to, or it is consumed as stock and the machine's recorded cost is unchanged. Decide which of those two you want before it happens rather than after.
Does the system know the SYSCOHADA chart of accounts?
No, and it does not hold a fixed-asset chart of accounts of any kind. Category is a free-text field of up to 120 characters with nothing behind it — no account code column, no validation, no link to a plan. That is deliberate for a product used across many countries, and it means the discipline has to be yours: agree the category values against your plan before anyone registers an asset, and add an account code as a custom field if your subdivisions are fine enough to need one.
Are CFA franc amounts handled correctly?
Yes. Both West and Central African CFA francs are treated as zero-decimal currencies, so amounts are not carried or displayed with centimes that do not exist. Each asset holds its own currency, which matters when part of the fleet was bought in euros — the currency is recorded per asset rather than assumed, so two different currencies are not silently added together in a total.
Can we get a total of asset cost by account class?
Yes, and this is the practical payoff for keeping the category field disciplined. In the reporting module, assets are a dataset where category is an available grouping dimension and total purchase cost is an available measure, so grouping by category and summing cost is a standard report you can filter by purchase date and export to csv or pdf. Filtering the same dataset on retirement date gives you disposals. Those two exports are the fixed-asset handover to your accountant at each close.
