Convention Method

 

Convention Method

Conventions and Depreciation Methods in Oracle Fusion Assets

  Setting the scene

 When people in the Oracle Fusion Financials world say "convention method," they are almost always talking about

  something inside the Fixed Assets module — and more specifically about how the system decides when depreciation starts

  and how much of a period's depreciation an asset is entitled to in its first and last years of life. Two setup

  objects do the heavy lifting here: the Depreciation Method and the Prorate Convention. They are different things, they

  answer different questions, and yet they are so tightly linked in daily practice that consultants often discuss them

  in the same breath.

 

  The cleanest way to keep them apart is to remember the questions each one answers. The depreciation method answers

  "What formula spreads the asset's cost across its useful life?" The prorate convention answers "In the year I buy the

  asset and the year I retire it, how much depreciation do I actually get to take?" You need both, and you assign both,

  but they are not the same lever.

 

  I'll spend most of this explanation on the convention because that is the piece that confuses people, but I'll keep

  tying it back to the method so the full picture stays intact.

 

  Why a convention is even needed

 

  Think about a very ordinary situation. Your company runs a monthly calendar and your fiscal year is January to

  December. You buy a laptop and place it in service on the 18th of March. The laptop has a useful life of three years.

  Now ask yourself a deceptively simple question: how much depreciation should the laptop earn in that very first year?

 

  You could argue it should earn depreciation from the 18th of March onward, counted to the day. You could argue it

  should earn a full month for March because it was in service during March. You could argue it should only start in

  April because it arrived too late in March to matter. You could even argue, for simplicity, that anything bought in

  the first half of the year gets a full year and anything bought in the second half gets half a year. Every one of

  those is a legitimate accounting policy, and different companies, tax jurisdictions, and accounting standards

  genuinely make different choices.

 

  That bundle of choices is exactly what a prorate convention encodes. It is the rule that translates a real-world

  "in-service date" into a prorate date, and that prorate date is what the system uses to look up how much of the year's

  depreciation the asset is allowed to claim. Without a convention, the application would have no consistent way to

  handle the messy reality that assets rarely arrive neatly on the first day of a fiscal year and rarely retire on the

  last.

 

  The three calendars and dates you have to keep straight

 

  Before the convention makes sense, four dates and structures need to be clear in your head, because Fusion uses all of

  them and they are easy to muddle.

 

  First is the date placed in service (DPIS). This is the real business event — the day the asset became available for

  use. A user enters it when they add the asset, and it is the anchor for everything that follows.

 

  Second is the prorate date. This is not entered by anyone. The system derives it by taking the DPIS and running it

  through the prorate convention. The prorate date might equal the DPIS, or it might be pushed to the start of the

  month, the middle of the month, the start of the next month, the start of the year, the middle of the year, and so on,

  depending on which convention you picked.

 

  Third is the prorate calendar. This calendar divides the fiscal year into prorate periods and gives each period a

  starting point against which the prorate date is measured. It is what the system reads after it has the prorate date.

 

  Fourth is the depreciation calendar, which defines the actual periods in which depreciation is calculated and posted.

  Many implementations use the same calendar for both depreciation and prorating, but they are technically two separate

  assignments on the asset book, and there are good reasons to occasionally make them differ.

 

  So the flow, in plain language, is this: a user records when the asset went into service; the convention converts that

  into a prorate date; the prorate date is located on the prorate calendar; that location, combined with the

  depreciation method and life, tells the system the depreciation rate or fraction for the first year; and from there

  the depreciation calendar governs the rhythm of monthly or periodic charges.

 

  Common convention types and what they actually do

 

  It helps to walk through the conventions people most often configure, because the names alone do not always make the

  behaviour obvious.

 

  A following-month convention says, in effect, "ignore the partial month of acquisition; start depreciating from the

  first day of the month after the asset went into service." If you place a machine in service on the 18th of March, the

  prorate date becomes the 1st of April, and the asset earns no depreciation for March at all. Companies that do not

  want to fuss over partial months and prefer a slightly conservative start often like this one.

 

  A current-month or actual-month style convention says, "the asset earns a full month in the month it arrived." Place

  the machine in service any day in March — the 1st, the 18th, the 31st — and it earns a full month of March

  depreciation. The prorate date lands at the start of March. This is popular because it is simple to explain to a

  controller: "if you owned it during the month, you depreciate it for the month."

 

  A mid-month convention places the prorate date at the midpoint of the month of acquisition, so the asset earns roughly

  half a month in its first month regardless of which day it actually arrived. This is the convention many people

  associate with certain US tax treatments for real property, where the rule is essentially "everyone gets half a month

  in the month they start."

 

  A mid-quarter convention pushes the prorate date to the middle of the quarter in which the asset was placed in

  service. There are tax regimes that force this convention onto a company when a large share of its asset additions

  land in the final quarter of the year — it is a rule designed to stop businesses from buying everything in December

  and claiming a near-full year of depreciation.

 

  A half-year or mid-year convention is the broad-brush approach: every asset, no matter when in the year it arrived, is

  treated as though it arrived in the middle of the year and therefore earns half a year of depreciation in year one.

  The other half of that first year's worth then effectively spills into the year after the asset's nominal life ends.

  This is extremely common in tax books precisely because it is simple and even-handed across all additions in a year.

 

  A daily or actual-days convention counts depreciation to the day, so an asset placed in service on the 18th of March

  earns depreciation for the exact remaining days of March and onward. This gives the most precise result and is

  favoured under accounting frameworks that emphasize matching cost to the genuine period of use, though it makes the

  numbers slightly harder to eyeball.

 

  The point of listing these is not that you must memorize them, but that you see the spread of policy they represent —

  from "round it to the nearest whole month, the simple way" to "count every single day." The convention is the dial

  that sets that policy, and you can have different dials for different books.

 

  How the convention pairs with the depreciation method

 

  Now bring the method back into the conversation, because the convention only tells you the fraction of the year; the

  method tells you the shape of the spread across the whole life.

 

  A straight-line method spreads cost evenly. If an asset costs a sum and lives five years, each full year takes

  one-fifth. The convention then trims the first year down to whatever fraction the prorate date earns and shifts the

  remainder to the tail. Straight-line is the workhorse for book (corporate) reporting because it is smooth,

  predictable, and easy to defend.

 

  A declining-balance method front-loads depreciation, taking a larger bite in early years and tapering off. A 200%

  declining balance, often called double-declining, applies twice the straight-line rate to the asset's remaining net

  book value each year. Here the convention still governs how much of that first, biggest chunk you are allowed to

  recognize in year one. Pairing an aggressive declining-balance method with a half-year convention is a classic

  tax-book configuration.

 

  There are also table-based methods, where Oracle uses predefined rate tables — frequently the depreciation tables

  published by tax authorities — and the prorate convention literally determines which column of the rate table the

  asset reads from. This is the case where the convention and method are at their most intertwined: change the

  convention and you are physically reading different annual percentages out of the table.

 

  Then there are units-of-production methods, which depreciate based on usage rather than time — think of a vehicle

  depreciated by miles driven or a machine by hours run. Conventions matter far less here because the charge follows

  production volume, not the calendar, but the in-service date still sets the starting gate.

 

  The practical takeaway: when you sit down to design an asset category, you are choosing a combination — a method, a

  life, a prorate convention, and a prorate calendar — and the four together produce the depreciation schedule. Changing

  any one of them changes the numbers.

 

  Where you actually set this in Fusion

 

  In Oracle Fusion Assets the convention is not something you type onto each asset by hand in normal operation. It flows

  down through configuration so that data entry stays fast and consistent.

 

  The prorate convention itself is defined in the setup area for asset conventions, where you specify, for each prorate

  period of the year, the prorate date that an asset placed in service in that period should receive. You are

  essentially building the lookup table that turns "placed in service in this stretch of the calendar" into "use this

  prorate date."

 

  That convention is then attached, along with a depreciation method and a default life, to an asset category within a

  specific asset book. The category is the linchpin of defaulting in Fusion Assets — it is where the financial behaviour

  of a class of assets lives. So a "Computer Equipment" category in your corporate book might carry straight-line over

  three years with a current-month convention, while the very same physical assets in your tax book might carry a

  declining-balance method with a half-year convention. Same assets, two books, two policies, because each book's

  category assignment is independent.

 

  When a user adds an asset and selects its category and book, the method, life, and convention default in automatically

  from that category-book setup. The user supplies the date placed in service; the system does the rest, deriving the

  prorate date and computing the schedule. A user with the right privileges can override the defaulted method, life, or

  convention on an individual asset when a genuine exception calls for it, but in a healthy implementation those

  overrides are rare and deliberate, not routine.

 

  The role of multiple books

 

  One of the most important reasons conventions exist as a flexible, per-book setting is that almost every organization

  of any size keeps more than one set of asset records. There is typically a corporate book that feeds the general

  ledger and follows the accounting standard the company reports under, and one or more tax books that follow the rules

  of each tax jurisdiction the company operates in. Some organizations also run additional books for management

  reporting or for a secondary accounting standard.

 

  Each of these books can — and usually does — apply a different convention to the same asset. The corporate book might

  want the smooth, matched-to-use behaviour of a daily or current-month convention under straight-line. A tax book in a

  particular country might be legally required to use a half-year or mid-quarter convention with a prescribed

  declining-balance method drawn from a government rate table. The asset is added once, typically into the corporate

  book, and then mass-copied into the tax books, where each book reinterprets it according to its own

  method-and-convention assignment. This is the everyday reason a consultant has to be fluent in conventions: you are

  reconciling several legitimate but different views of the same physical asset, and the convention is one of the main

  reasons the numbers differ between those views.

 

  A worked illustration in words

 

  Let me walk a single asset through the logic so the moving parts click together, without drowning in arithmetic.

 

  Imagine a delivery van. The business places it in service on the 10th of September. The fiscal year is the calendar

  year, the books run a monthly calendar, and the van's category in the corporate book says: straight-line method,

  five-year life, current-month convention. Because the convention is current-month, the system sets the prorate date to

  the 1st of September — the van earns a full month for September even though it arrived on the 10th. With a five-year

  straight-line spread, the van earns one-fifth of its cost per full year, but in that first calendar year it is only in

  service for four months — September through December — so it earns four-twelfths of that annual amount in year one.

  The leftover eight-twelfths of a year's worth gets recognized after the fifth nominal year, in what is effectively a

  sixth partial year, until the cost is fully exhausted. That tail is the natural consequence of starting partway

  through a year — depreciation has to end up somewhere, and the convention is what decided where the schedule begins,

  which in turn decides where it ends.

 

  Now copy that same van into a tax book whose category says: declining-balance from a published rate table, with a

  half-year convention. The half-year convention treats the van as if it went into service in the middle of the year

  regardless of the September date, so it earns half of the first table year's percentage in year one. Because it is

  declining-balance, that first year's percentage is large, so even a half portion of it is a meaningful charge —

  generally far larger than the corporate book's modest four-twelfths of a straight-line fifth. Right there, in year

  one, the two books already disagree about the van's depreciation, and they will keep disagreeing through its life.

  Neither is wrong. They are answering to different rule sets, and the convention is one of the principal reasons the

  two schedules diverge.

 

  This is the kind of thing a functional consultant has to be able to explain to a controller who walks over and asks,

  "Why does the van show one number in our financials and a completely different number on the tax schedule?" The

  honest, complete answer always touches the convention.

 

  Retirements and the convention's other half

 

  People tend to focus on the convention's role at the start of an asset's life and forget it has just as much to say at

  the end. When an asset is retired — sold, scrapped, given away — the convention again governs how much depreciation

  is taken in that final period or year. Some conventions grant a full final period; some grant none in the period of

  retirement; some, like the half-year family, grant half a year in the year of disposal as a counterpart to the half

  year they granted at acquisition. This symmetry is deliberate. The half-year convention's whole logic is that, on

  average across many assets, granting half a year at the start and half a year at the end smooths out the distortions

  of not knowing the exact day. So when you choose a convention you are choosing behaviour at both ends of the asset's

  life, not just the beginning, and a consultant who only thinks about the addition side will be caught off guard by the

  disposal numbers.

 

  Common pitfalls and how to think about them

 

  A few traps come up again and again, and naming them is more useful than any amount of theory.

 

  The first is confusing the depreciation calendar with the prorate calendar. They are separate assignments on the asset

  book and they serve separate purposes. The depreciation calendar sets the rhythm of charges; the prorate calendar

  sets the granularity at which the convention can place a prorate date. If your convention promises monthly precision

  but your prorate calendar only has quarterly periods, the convention cannot deliver what you think it will, because

  the prorate date can only land on the boundaries the prorate calendar offers. Mismatches here produce surprises.

 

  The second is assuming the convention can be changed casually after assets are live. Once assets have depreciated

  under a convention, switching it is not a cosmetic edit — it changes the entire calculation basis and can require

  careful handling, sometimes amortizing the adjustment over the remaining life rather than restating history. The

  convention is a foundational decision, best settled during design and tested hard before go-live, not adjusted on a

  whim afterward.

 

  The third is forgetting that tax conventions may be legally mandated, not a matter of preference. In several

  jurisdictions the convention and method for a given asset class are dictated by the tax code, and the mid-quarter rule

  in particular can be triggered by the timing of a year's additions rather than chosen freely. A consultant

  configuring a tax book has to know the local rules, not just the software, because the software will happily let you

  pick a convention the tax authority would reject.

 

  The fourth is over-overriding at the asset level. Because Fusion lets a privileged user override the defaulted

  convention on an individual asset, it is tempting to fix one-off situations by hand. Every manual override, though, is

  a future reconciliation headache and a thing that has to be remembered and explained. The discipline is to get the

  category-and-book defaults right so that overrides become genuinely exceptional, and to document the ones you do make.

 

  The fifth, and subtlest, is treating the method and convention as interchangeable in conversation. They are not. When

  a stakeholder says "the depreciation looks wrong," part of the consultant's job is to figure out whether the issue

  lives in the method (the shape of the spread), the life (how long), the convention (the first- and last-year

  fractions), the prorate calendar (the granularity), or the in-service date the user typed. Sloppy language about "the

  convention method" as if it were one undivided thing makes that diagnosis harder. Keeping the vocabulary precise —

  method here, convention there — is part of being good at this.

 

  How to talk about it with a client

 

  When you are explaining this to a finance team that does not live inside the software, the framing that lands best is

  the question-and-answer one I opened with. Tell them: "The method is the recipe for spreading the cost; the convention

  is the rule for the first and last years, when the asset wasn't around for the whole year." Then give them the

  concrete fork: "Do you want assets to earn depreciation from the month they arrive, from the following month, half a

  year regardless, or counted to the day?" Most finance people have an immediate instinct about that, and their

  instinct, once you translate it into a convention, becomes your configuration.

 

  For the tax side, the conversation is less about preference and more about compliance: "What does the tax authority in

  each country require for each asset class?" There you are gathering constraints, not opinions, and the convention you

  configure has to honour them exactly.

 

  And for the reconciliation question that always eventually comes — "why don't the books agree?" — the convention is

  one of your standard answers, alongside method and life. Being able to point to it specifically, and to walk through a

  single asset the way I did with the van, is what turns a vague "the systems just calculate differently" into a

  credible, defensible explanation.

 

  Pulling it together

 

  The convention, then, is a small setup object with an outsized influence. It quietly converts the human fact of "we

  started using this on the 10th of September" into the precise prorate date the engine needs, and through that date it

  shapes the first and last years of every asset's depreciation. It works hand in glove with the depreciation method,

  the life, and the prorate calendar, and it lives on the asset category within each book so that the same physical

  asset can follow one policy in your corporate accounts and entirely different policies in each tax book. Get it right

  at design time, keep its vocabulary distinct from the method's, respect the legal mandates on the tax side, and keep

  manual overrides rare, and the convention becomes invisible in the best way — assets just depreciate the way the

  business and the tax code expect, year after year, without anyone having to think about the machinery underneath.

 

  That underlying machinery is exactly what separates someone who can click through the Add Asset page from someone who

  can stand in front of a controller and explain, with a straight face and a worked example, why two perfectly correct

  books disagree about the same van. The convention is a big part of that story, and now you have the whole shape of it

  to retell in your own words.