Imagine this scenario if you will. You have a slick way of planning for Dues & Subscriptions by vendor dimension in a modeled sheet where you can input rows of details by vendor dimensions with text descriptions. You’re doing this because you want a way to provide reports by vendor to your department managers.
Then one day someone asks, “I know how much I’m planning for a certain vendor, but how much did I actually spend last year?” This is easily answered by producing a report that displays actuals for last year by vendor dimension, because you have actuals imported into Adaptive at the vendor dimension granularity.
Then, your IT manager asks you, “what is the variance by vendor that we spent between our plan vs. actuals for last year?” This scenario gets a little harder to do because you wouldn’t be able to show actuals against plan by dimensions if your Adaptive model is implemented in a way where your modeled sheet expense detail is mapped to your GL accounts using shared formulas.
The report you’d want to create would be to display a GL account, in this case the 6605 account by vendor, and add in your actuals and plan versions together on the same report with a variance column. The problem is, however, that although using a shared formula (or a sheet level formula) brings in the right value from a modeled sheet or a cube sheet, the shared formula strips away any dimensionality when the values are displayed on the income statement for the GL account.
You’ll be able to see the actuals value for account 6605 along with planning data with the variance, but only at the account level, not by vendor. This is where linked accounts come in.
Instead of using a shared formula on the GL account, within the GL account settings we have the ability to directly link modeled and cube sheet accounts. When we use the linked account feature, all dimensionality is maintained at the most granular detail to the GL accounts.
This means that when you lay the actuals alongside planning versions on a report by vendor, you’ll see a line for line matchup between those versions on the report, giving you a view into detailed dimensional data between actuals and plan.
This is an amazing capability, but there are some downsides to using linked accounts. One being that when you set up a linked account, it will remove any planning data already entered in planning versions for that account. So, if you are well beyond your implementation and have many planning versions already under your belt, you may want to consult with your implementation specialist for ways to get around losing your previous planning data.
Another issue with linked accounts is that linked accounts forces the data entry to be done at the account where the GL account is linked to. For example, setting up an expense planning input modeled sheet would force the data entry to be done in that sheet rather than at the GL account line in the income statement.
While some finance professionals would see this as a limitation, others see this as a significant benefit to their process because it enforces a single layer of data entry and maintenance. There are always workarounds, so please contact your implementation specialist for more details if you're experiencing any frustration deploying or managing linked accounts.