Fixed Assets Management in Business Central

Almost every Business Central implementation reaches a moment where someone from finance asks how the company is going to track its buildings, vehicles, plant and equipment, and whether the old spreadsheet can finally be retired. The answer is that Business Central has a proper fixed assets module built in, one that most teams underuse because it looks intimidating at first glance. It is not intimidating once you see the shape of it. There is an asset, there are one or more depreciation books attached to that asset, and there is a small set of journals and posting rules that move value onto the asset, wear it down over time, and eventually take it off the register. Everything else is detail hanging off that skeleton. This guide walks the full lifecycle the way I set it up in real projects, and it is honest about the places where the accounting reality and the tax reality pull in different directions.

The message up front: fixed asset accounting in Business Central is not hard, but it is unforgiving of a rushed setup. The two decisions that matter most, how many depreciation books you run and how your FA posting groups map to the general ledger, are made once at the start and are painful to unwind later. Spend your effort there and the rest of the lifecycle mostly takes care of itself.

1. What the fixed assets module is for (and why spreadsheets stop working)

The fixed assets module exists to answer a set of questions that finance is legally and practically obliged to answer at any moment: what does the company own, what did each item cost, what is it worth today after depreciation, how much depreciation has hit the profit and loss this year, and what happened when something was sold or scrapped. A spreadsheet can hold those numbers, and for a handful of assets it does the job. The problem is not that a spreadsheet cannot store the data, it is that a spreadsheet cannot keep the data reconciled to the general ledger, and reconciliation is the whole point.

In Business Central, an acquisition posted against a fixed asset simultaneously updates the asset record and posts to the balance sheet. A depreciation run simultaneously reduces the asset book value and posts the expense to the profit and loss. Because the two sides move together, the fixed asset sub-ledger always ties back to the control accounts in the general ledger, and the finance team can prove at year end that the register agrees with the accounts to the fils. That structural guarantee is what a spreadsheet can never offer, because a spreadsheet is a parallel record that drifts the moment someone forgets to update it.

Spreadsheets stop working for four practical reasons that show up in every growing organisation. Volume, once you pass a few dozen assets the manual depreciation maths becomes error-prone. Audit, external auditors want to trace an asset from purchase invoice to disposal and a spreadsheet gives them nothing to trace. Tax, the day you need to depreciate the same asset one way for the accounts and another way for tax, a single spreadsheet column collapses under the contradiction. And people, spreadsheets live on one person's machine and leave with that person. Business Central removes all four problems by making the asset register a native, posted, reconciled part of the ledger rather than a document that sits beside it.

2. Fixed asset cards, classes, subclasses and groups

Every asset in Business Central lives on a fixed asset card. The card is the master record: it carries the asset description, the responsible employee, the location, the class and subclass, and importantly the depreciation book lines that define how the asset is depreciated. One card can carry several depreciation book lines, which is the mechanism that lets a single physical asset be depreciated differently for accounting and for tax at the same time. Hold that idea, because it is the single most useful thing to understand about the whole module.

Above the individual card sit three grouping dimensions that keep a large register organised and reportable:

• FA Class is the top-level grouping, typically aligned to how assets appear on the balance sheet: tangible fixed assets, intangible assets, and so on. It is broad and it changes rarely.
• FA Subclass sits under the class and is where most of the useful categorisation happens: buildings, motor vehicles, IT equipment, plant and machinery, office furniture. The subclass is a natural place to standardise the default posting behaviour, because assets of the same subclass usually share the same general ledger accounts and often the same depreciation approach.
• FA Location records where the asset physically sits, which matters far more in a multi-site operation than people expect, and it pairs with the responsible employee field to answer the custody question of who is accountable for the item.

Alongside these there is the FA Posting Group, which is arguably the most important field on the card because it is the bridge to the general ledger. The posting group is a named set of general ledger accounts, one account for the acquisition cost, one for accumulated depreciation, one for the depreciation expense, and separate accounts for gains, losses, write-downs and disposals. When you post any transaction against the asset, Business Central reads the posting group to decide which ledger accounts to hit. Get the posting groups right and every posting lands in the correct account automatically. Get them wrong and you spend year end untangling misposted depreciation. I treat posting group design as a finance decision, not an IT one, and I get the controller to sign off the account mapping before a single asset is created.

A common early mistake: creating one giant posting group for everything to save setup time. It works until finance wants to see motor vehicles depreciation separately from IT equipment depreciation in the ledger, and by then hundreds of assets already point at the shared group. Design posting groups around how finance wants to read the accounts, usually one per asset subclass, and you will never have to reclassify the whole register later.

3. Acquisition and capitalization (from purchase to asset)

Getting cost onto an asset is called acquisition, and Business Central gives you two routes that suit two different situations. The first and cleanest route is to acquire the asset directly from the purchase document. When you enter a purchase invoice or purchase order, you set the line type to Fixed Asset and pick the asset card on the line. When that document posts, the cost flows straight onto the asset as its acquisition cost, the vendor is credited, and the balance sheet asset account is debited, all in one posting. This is the route I always prefer because it keeps a clean audit trail from the vendor invoice directly to the capitalised asset, which is exactly the trail an auditor wants to walk.

The second route is the FA G/L Journal, where you post an acquisition cost manually against the asset and a balancing account. This is the route for opening balances when you first go live and are loading a register that already exists, or for assets that were built up from costs that did not arrive as a single tidy invoice. The distinction to keep clear is between the FA G/L Journal, which posts to both the asset and the general ledger, and the plain FA Journal, which posts only to the fixed asset ledger without touching the general ledger. You use the plain FA Journal for depreciation books that are deliberately kept outside the accounts, which is a tax-book scenario we will get to shortly.

Capitalization is the accounting judgement that a cost is an asset rather than an expense, and Business Central does not make that judgement for you, it simply records the decision once a human has made it. The practical discipline is to decide a capitalisation threshold with finance, below which small purchases are expensed rather than capitalised, so the register does not fill up with staplers and keyboards. Assets under construction, where cost accumulates over months before the asset is ready for use, are handled by accumulating the cost and only starting depreciation once the asset is placed in service, which brings us to depreciation itself.

4. Depreciation books and methods (straight-line, declining balance, and others)

A depreciation book in Business Central is the rulebook that says how value is written off over time. Each asset is attached to one or more depreciation books through the FA depreciation book lines on its card, and each of those lines carries the method, the useful life or rate, the depreciation starting date, and the accounts via the posting group. The book is where the mechanics live, and Business Central ships with a solid set of methods that cover the vast majority of real-world requirements.

• Straight-Line spreads the depreciable amount evenly across the useful life. You express the life either as a number of depreciation years or as an ending date, and Business Central divides the value to be written off across the periods between the starting date and the end of life. It is the default for most accounting books because it is simple, predictable, and matches how most companies want their profit and loss to absorb the cost.
• Declining-Balance applies a fixed percentage to the reducing book value each period, so depreciation is heavy early and tapers off later. Business Central offers Declining-Balance 1 and Declining-Balance 2, which differ in how the percentage is applied across periods within a year, and this front-loaded profile is common in tax books because many tax regimes allow accelerated write-off.
• DB1/SL and DB2/SL are hybrid methods that apply declining balance while it gives the larger deduction, then switch to straight-line once straight-line would write off more, which maximises the deduction in each period. These are workhorses of tax depreciation in jurisdictions that permit the switch.
• User-Defined lets you enter a depreciation table with your own percentages per period, which is how you handle statutory schedules that do not fit any standard curve, and unit-of-production style approaches where wear is tied to usage rather than time.
• Manual disables automatic calculation entirely, so depreciation is only ever what you post by hand. It is the right choice for assets like land that are not depreciated at all, and for special cases where finance wants to control the figure directly.

Two settings on the book line deserve attention because they quietly shape every number that follows. Salvage value is the residual amount you do not depreciate below, and if you set it, the depreciable base becomes cost minus salvage rather than the full cost. And the depreciation starting date is what actually triggers depreciation to begin, so an asset acquired in one month but placed in service the next should carry the in-service date as its starting date, not the purchase date, or the depreciation timing will be wrong from day one.

5. Running multiple depreciation books (accounting vs tax, and reporting differences)

This is the section that separates a competent fixed asset setup from a fragile one, and it is the feature that finally kills the spreadsheet. In most jurisdictions the way you depreciate an asset for your published financial statements is not the way the tax authority lets you depreciate it for your tax return. The accounts might use straight-line over ten years to reflect the true economic life, while the tax rules might allow a faster declining-balance write-off to encourage investment. One physical asset, two entirely different depreciation stories, running in parallel for the asset's whole life.

Business Central handles this natively by letting you attach more than one depreciation book to the same asset. You create an accounting book, integrated with the general ledger, that drives your financial statements. You create a separate tax book, and here is the key design choice, that tax book is typically not integrated with the general ledger, because tax depreciation is a memorandum calculation for the tax return and must not disturb the statutory accounts. Both books share the same acquisition cost and the same asset, but each applies its own method and life and produces its own book value and its own depreciation figure.

The mechanics that make this manageable are worth naming. When you acquire an asset you can have Business Central duplicate the acquisition into the second book automatically, so you do not enter the cost twice. When you run depreciation you run it per book, so the accounting book posts to the ledger and the tax book updates only the fixed asset sub-ledger. And the difference between the two book values at any point, the timing difference between accounting and tax depreciation, is exactly the figure the accountants need to compute deferred tax. The system does not calculate deferred tax for you, but it hands you the two book values that the deferred tax working depends on, which is most of the battle.

The insight that saves projects: decide your depreciation book structure before you load a single asset. Adding a second book to a register that already has hundreds of assets and years of posted depreciation is possible but genuinely painful, because you have to seed the new book with correct opening cost and accumulated depreciation for every asset. Sit down with finance at the very start, ask whether a tax book will ever be needed, and if the honest answer is even a maybe, create it from day one. It costs almost nothing to run an extra book that stays quiet, and it costs a great deal to bolt one on later.

6. Posting depreciation and the FA journals

Depreciation in Business Central is a two-step process by design, and the separation is deliberate and useful. First you calculate depreciation, which is a batch job that reads each asset's depreciation book, works out the depreciation due up to a date you specify, and writes proposed depreciation lines into a journal. Nothing has hit the ledger yet at this stage. Second you review those proposed lines and post the journal, and only then does the depreciation become permanent, reducing the asset book value and, for an integrated book, posting the expense to the profit and loss and the accumulated depreciation to the balance sheet.

The reason the two steps matter is control. The calculate step gives finance a chance to look at what depreciation is about to be posted before it becomes real, to catch an asset with a wrong starting date or a life that was keyed incorrectly, and to correct it before month end closes rather than after. I always coach teams to treat the calculated journal as a review gate, not a rubber stamp, especially in the first few periods after go-live when setup errors are still surfacing.

The journals themselves come in two flavours that map onto the integrated-versus-not distinction from the previous section. The FA G/L Journal is used for depreciation books that are integrated with the general ledger, because posting from it updates both the asset and the accounts. The FA Journal, without the G/L, is used for books that are not integrated, such as the tax book, because it updates only the fixed asset ledger and leaves the accounts untouched. When you run the calculate depreciation batch you tell it which document and journal to populate, and the same batch can handle both books, sending the accounting depreciation to the FA G/L Journal and the tax depreciation to the plain FA Journal. Understanding which journal a book belongs to is the difference between clean books and a tax calculation accidentally polluting your statutory accounts.

7. Maintenance, insurance and the asset registers

Beyond depreciation, Business Central carries two supporting capabilities on the fixed asset that are easy to overlook and genuinely useful. The first is maintenance registration. You can record maintenance costs against an asset without capitalising them, which lets finance see the running cost of keeping an asset serviceable over its life alongside its depreciation. This is not a maintenance management system, and I want to be clear about that below, but as a financial record of maintenance spend per asset it answers a real question: is this ageing vehicle costing more to keep running than it is worth.

The second is insurance. Business Central lets you set up insurance policies, link assets to them, and record the insured value against each asset, so you can compare the total insured value of a group of assets against their policy coverage and spot assets that are under-insured or not insured at all. For an organisation with a large or valuable asset base, this insurance coverage view turns a scattered set of policy documents into a reconciled picture of what is covered and for how much.

The registers are the audit backbone. Every posting to a fixed asset is recorded in the FA register and the FA ledger entries, giving a complete, traceable history of every asset from the day it was acquired to the day it left the books. When an auditor asks to see the life of a single asset, this history is what you show them: acquisition, every depreciation entry, any write-down or appreciation, any transfer, and the final disposal, each entry tied back to the document and the user that posted it. That traceability is the quiet reason to keep the register inside the ERP rather than in a spreadsheet.

An honest note from the maintenance side of my desk: the fixed assets module is financial asset accounting, and it is not the same thing as physical asset and maintenance management. My day job runs CMMS and CAFM platforms where an asset carries work orders, PPM schedules, spare parts, condition data, failure history and a maintenance team's whole workflow. Business Central knows an air handling unit as a line of cost that depreciates over fifteen years. A CAFM or EAM system knows the same unit as a serviceable object with filters to change and a fault history. Both records are legitimate and they answer different questions. The common mistake is expecting the finance module to run maintenance, or expecting the maintenance system to keep the books. When both matter, you integrate them, you do not collapse one into the other.

8. Disposals, write-downs and appreciation

Assets leave the books, and disposal is how Business Central records the exit. When you sell or scrap an asset you post a disposal, either through a sales document with a fixed asset line if the asset is being sold to a customer, or through the FA G/L Journal for a scrapping with no proceeds. The disposal posting does the full set of movements automatically: it removes the acquisition cost, removes the accumulated depreciation, recognises any sale proceeds, and calculates the gain or loss on disposal as the difference between the net proceeds and the remaining book value. The gain or loss lands in the accounts you defined on the posting group, which is why getting those posting group accounts right at the start pays off again here.

Two other value movements are worth knowing because finance occasionally needs them. A write-down is a reduction in an asset's value below its depreciated book value, used when an asset is impaired, damaged or simply worth less than the books say. You post it as a write-down entry, which reduces the book value and posts the write-down to the account defined for it, keeping the impairment visible and separate from ordinary depreciation. Appreciation is the opposite, an upward revaluation, used far more rarely and usually only where accounting standards permit a revaluation model, for example on property. Business Central supports it as an appreciation posting so that a genuine revaluation can be recorded through the module rather than bypassing it.

The discipline around disposals is timing. An asset sold mid-period should usually be depreciated up to the disposal date before the disposal is posted, so the final period's depreciation and the resulting gain or loss are both correct. Posting the disposal without first bringing depreciation up to date is a frequent source of a slightly wrong gain figure that the auditors then query. Depreciate to the disposal date, then dispose, and the numbers come out clean.

9. Reclassification, splits and transfers

Assets do not always stay as they were first recorded, and the FA Reclassification Journal is the tool for restructuring the register without breaking the audit trail. It handles three related operations. A transfer moves an asset, or part of its value, from one asset to another, which is how you move an asset between FA classes or reassign it when its categorisation was wrong. A split takes one asset and divides it into several, which is common when a single capitalised purchase actually represents several distinct assets that should be tracked and disposed separately. And a combine, or partial transfer, merges value from several assets into one where the opposite is true.

What makes the reclassification journal the right tool, rather than manually reversing and re-entering, is that it carries the acquisition cost and the accumulated depreciation together in the correct proportion. When you split an asset into two, the depreciation already taken is divided along with the cost, so both resulting assets carry a consistent history and the total book value is unchanged by the split. Doing this by hand almost always produces an inconsistency between cost and accumulated depreciation that surfaces later as a reconciliation difference. Let the journal do the proportional maths.

Transfers between locations and changes of responsible employee are a lighter touch, handled by updating the fields on the card rather than by a reclassification, because they change custody and reporting rather than value. The rule of thumb I use: if value moves, use the reclassification journal so cost and depreciation stay together, and if only custody or categorisation moves without changing value, update the card fields directly.

10. Integration with the general ledger and purchasing

The reason fixed assets belongs inside Business Central rather than beside it is integration, and it runs in two directions. Toward the ledger, every posting that touches an integrated depreciation book simultaneously posts to the general ledger through the FA posting group, so the fixed asset sub-ledger and the balance sheet control accounts are always in agreement by construction. There is no month-end reconciliation ritual of matching a spreadsheet to the accounts, because the two were never separate to begin with. This is the same tight sub-ledger-to-ledger relationship that runs through the rest of the finance area, and if you want the wider context of how the ledgers hang together, the financial management guide covers the general ledger, dimensions and posting groups that fixed assets plugs into.

Toward purchasing, the fixed asset line on a purchase invoice or order is the clean on-ramp for acquisition. Because the asset is capitalised from the same document that records the vendor liability, there is no gap between when the invoice is booked and when the asset appears on the register, and no chance of an asset being paid for but never capitalised. The vendor, the cost, the balance sheet and the asset card all move in one posting. This end-to-end thread, from vendor invoice to capitalised, depreciating asset to eventual disposal, all inside one system, is exactly what a spreadsheet register can never provide, and it is why finance teams that adopt the module properly rarely go back.

Dimensions are the other integration worth calling out. Business Central dimensions, the tags such as department, project or cost centre that you attach to postings, flow through fixed asset transactions too, so depreciation expense can be analysed by department or a group of assets reported by cost centre without creating separate general ledger accounts for each. For an organisation that wants to see asset cost and depreciation sliced by business unit, dimensions do the work that a proliferation of accounts used to do badly.

11. Reporting on fixed assets

A register you cannot report on is just an expensive list, and Business Central ships a set of fixed asset reports that answer the questions finance actually asks. The most used in practice are the book value reports, which show for a period the opening book value, additions, depreciation, disposals and closing book value for each asset or group, and which are the natural basis for the fixed asset note in the financial statements. There is a projected value report that looks forward and estimates depreciation for future periods, which is invaluable for budgeting because it tells finance what depreciation expense to expect next year from the assets already on the books.

The analysis reports let you slice the register by class, subclass, location or dimension, and compare figures across depreciation books, which is where the accounting book and the tax book can be reported side by side to show the timing difference between them. The register report gives the audit-oriented, entry-by-entry history that external auditors want. And because fixed asset data lives in the same database as everything else, the same figures are available to the wider analytics and reporting tools rather than being locked inside a standalone application. If you want the broader picture of where fixed assets sits among the rest of the Business Central modules, the complete features guide maps the whole application.

The practical reporting advice I give is to standardise on a small number of reports that finance runs every month, the book value movement for the accounts and the projected value for the budget, and to resist the temptation to build a bespoke report for every question. Most fixed asset questions are answered by the standard reports plus a dimension filter, and the teams that get value from the module are the ones that run the same tight set of reports consistently rather than reinventing the reporting each period.

12. Practical setup advice and common mistakes

Having set this module up across several implementations, the mistakes cluster into a predictable list, and every one of them is cheaper to avoid at the start than to fix later:

• Not planning the depreciation books up front. As covered above, retro-fitting a tax book onto a live register is painful. Decide the book structure before loading assets, and create the tax book from day one if there is any chance you will need it.
• Over-simplifying the posting groups. One shared posting group for the whole register saves an hour at setup and costs weeks later when finance wants depreciation split by asset type in the ledger. Design posting groups around how the accounts should read, usually one per subclass.
• Confusing acquisition date with depreciation starting date. Depreciation begins from the starting date, not the purchase date. An asset bought in advance of being placed in service must carry the in-service date, or its depreciation timing is wrong for its whole life.
• Loading opening balances carelessly at go-live. When you migrate an existing register you must seed each asset with both its original cost and its accumulated depreciation to date, in every book. Getting the accumulated depreciation wrong means every future book value is wrong. This is the single most error-prone step in a fixed asset go-live and it deserves careful reconciliation against the legacy register.
• Posting disposals without depreciating to the disposal date first. This produces a slightly wrong gain or loss that auditors will find. Depreciate up to the disposal date, then dispose.
• Skipping the review of the calculated depreciation journal. The calculate-then-post design exists to give you a review gate. Posting the calculated journal blind, especially in the early periods, lets setup errors become posted entries that then have to be reversed.
• Expecting the module to manage maintenance. It records maintenance cost, it does not manage maintenance work. If you need work orders, PPM and asset condition, that is a CMMS or EAM job, integrated with finance rather than replaced by it.

The positive version of all of this is short. Spend real time with finance on two decisions at the start, the depreciation book structure and the posting group mapping, and load the opening balances carefully with a reconciliation you can prove. Do those three things well and the rest of the lifecycle, acquisition, depreciation, disposal, reclassification, is largely a matter of running the standard routines and reviewing before you post. The module rewards a careful setup with years of clean, reconciled, auditable asset accounting.

Final thoughts

Fixed asset accounting in Business Central is one of those areas that looks more complicated than it is because the terminology arrives all at once. Once you see that an asset is just a card carrying one or more depreciation books, that a book is just a rulebook for writing off value, and that a small set of journals move value on, wear it down and take it off, the whole module falls into an understandable shape. The genuinely hard parts are not the software, they are the accounting judgements the software records: what to capitalise, over what life, and how the tax treatment differs from the accounts. Business Central gives you clean, native mechanisms for all of it, and it keeps the register reconciled to the ledger in a way a spreadsheet never can.

If you take one thing from this guide, let it be that the fixed asset setup is a place to be deliberate rather than fast. The book structure and the posting groups are decisions you make once and live with for years, and the opening balance load is the one step where a quiet error propagates into every future number. Get those right, keep the finance module doing finance and let a proper CMMS or EAM handle the physical maintenance side, and Business Central will run your fixed asset lifecycle cleanly from the first acquisition to the last disposal.

Related reading: Financial management in Business Central, Business Central features: the complete guide.