Borrowing on the accounting terminology, a line item is the lowest level of granularity that should be considered in the build-up of a model. Akin to considering that the atom is not divisible in chemistry (only in nuclear physics), a line item is the lowest level structure in a model and should not be corrupted.
A modeller must have a clear understanding of how a line item is classified, its taxonomy. General design principles can include:
1. Is the line item a constant or a series?
2. Is the line item cash or not-cash?
3. Is the line item a flow or a balance?
4. If the line item is a flow, is it an in-flow or an out-flow from the business or project?
5. If the line item is a balance, is it an opening (brought forward) or closing (carried forward) position?
FAST 3.01-01 Provide clear indication for constants vs series
As constants, by definition, are not time based, they require their own column separate from the time based columns.
This rule is supported by the rules FAST 2.01-03: Make only two columns matter and FAST 2.01-01: Each column should have a single and consistent purpose.
FAST 3.01-02 Treat line items as the smallest indivisible object in a model
Treat a line item as an autonomous, incorruptible unit of information. Do not link to sub-parts of a line item, including displaying only part of its time range except in the rarest examples. Pass the label, units designator, and display total on through to any link.
FAST 3.01-03 Do not use a series structure to present constants
It is tempting to pre-build the flexibility for series constructions on values that do not vary over time, but this temptation should be avoided; adapt the model as/if such circumstance actually materializes.
This rule applies to inputs in particular. Many inputs in a model are constants and will not change over time. Updating the numbers across the timeline is a relatively tedious and error-prone job compared with updating the single cell that defines a constant.
FAST 3.01-04 Do not use row totals in model logic
A row total provides useful information and serves to highlight the line item in question being a flow (certainly not a balance). However, if a row total is required to be actively used, for example the SUM of discounted cash flows, then a separate (constant) line item should be created with its own row. Row totals should have no substantive dependents, and hence be ‘display only’, i.e. display totals. (This rule is further supported by FAST 2.01-03: Make only two columns matter.)
Even cross-totalling via adding Display Totals from precedent line items should be avoided, though may be sensible as a check performed elsewhere. A missing Display Total, which is a non-structural element, should therefore not raise any concern on the part of the modeller.
FAST 3.01-05 Include display totals on all flows
Totals of flows are informationally important and can assist in spotting errors. Include a display total in a column dedicated for this purpose. Together with FAST 3.05-06: Include the word “balance” in labels of balances, page 35, this rule is a good way to provide clear distinction.
FAST 3.01-06 Do not include display totals on balances
FAST-3.01-06.1 except when the line item includes a single balance
In this case a flag should be used to select the balance at that point of time and display it in the constants column.
FAST 3.01-07 Place display totals on the left where they are visible
FAST 3.01-08 Make numbers look like what they are with smart format
Use formatting to assist with fast and easy comprehension. Format non-monetary quantities to a resolution that is unlikely to be ‘money’, for example four decimals for factors, single decimal place for indices. Conversely, monetary units (other than dollars and cents) should be formatted in engineering notation: no decimals or in groups of three.
