Silverfin is a multi-function tool that is used for many different workflows of the accountant, that can include, but is not limited to:
- Accounts preparation work papers
- Account production
- Corporation Tax
- GAAP bridges
- Analytics
When we considered how best to do rounding, we needed to think of a solution that could work for all these use cases, not only individually, but also in combination with one another, as our clients often will use multiple different workflows on a single company.
As a result, we needed to devise a solution that considered:
- different workflows (and therefore template set), and handling of different degrees of rounding in each (e.g. tax might require rounding to the nearest $, but the accounts, the nearest $'000)
- level of aggregation of the accounts appearing in the different workflows, some templates listing the individual accounts (each revenue TB account), others looking at the aggregation of groups of accounts (say grouping 'revenue' to one line)
- Flexibility, ease of use, and consistency in applying the rounding within a template
- Efficiency of the rounding function for performance reasons
On the basis of that analysis we concluded:
- Rounding would be dealt with as a core function, but could be chosen to be applied in different places in a liquid template, so each usecase could be individually supported
- To be consistent with how we round, that rounding would be done on an individual account level, so instances of individual accounts displayed, when aggregated, would match the values for rounding groups of accounts.
- With rounding being applied only where the effects are significantly immaterial (i.e you only typically round when the numbers get big, and the rounding is the insignificant to the users), any difference between the two methods would in aggregate also be significantly immaterial to the user.
- To enable the users flexibility to offset some of the effects of rounding, they should be able to choose where to post the rounding difference.
Whilst we can also see merit in the other options for rounding and in isolated usecases (such as rounding at a group level in financial statements) this would cause an equal amount of issues within other usecases in Silverfin, and would also cause complexity, rigidity, reduced performance and inconsistency in the Silverfin templates across different workflows.
Before making this decision we also looked at other software providers (some of which were specifically accounts production tools) and the split between rounding at a group level and rounding at an account level was split evenly amongst the providers, which also reinforced our decision to stick with a solution that works for the wide variety of usecases in Silverfin.