Best practice for rolling forward from Q3 10Q to 10-K and back to Q1 10Q
Our team is just implementing Workiva now and trying to determine the best way to house and link support for the footnotes. Prior to implementing Workiva, we had support in excel workbooks that produced numbers used in footnotes of the 10-Q. We were considering importing these as tabs within the 10-Q spreadsheet and linking the cells that push to the 10-Q directly from the work-paper support within the 10-Q spreadsheet. However, recently we learned that the 10-K spreadsheet is a different workbook from the 10-Q workbook. So we would have to copy and paste all the support tabs from the 10-Q project to the 10-K project and then back to the 10-Q project in Q1? Is that what's best practice? If not what have other teams found to be the most efficient?
-
Hi Anthony,
Exciting to have you onboard with Workiva! Thanks for reaching out.
While I can't speak for the best practices across the board, per se, I can say that your question is a common one, i.e. how best to maintain two spreadsheets that likely share many of the same item.
One approach would be to actually have one primary spreadsheet, sometimes called "single source", that has your yearly and quarterly data within it that is rolled forward with your 10K and 10Q each quarter. This keeps only one set of links and maintains the XBRL tagging, keeping it updated. Your spreadsheet might have some sheets specific to your Q and some specific to your K, but items like your face statements would likely be linked to both places so you have only one set of those.
Some caveats to this method is that when you roll forward, you need to roll forward all the files together, 10K, 10Q, Spreadsheet, and any exhibits or other files also linked (like an earnings release). Additionally, when you migrate XBRL taxonomies, you'll need to make sure to migrate both your 10K and 10Q at the same time. And of course, to get this setup, you'll have a bit of a lift in the beginning to get all your links in one place and keep your XBRL intact. Your CSM would likely be able to give you some pointers here too.
Other methods could include having separate Spreadsheets or sheets within your Spreadsheet that are fed from a central repository sheet, like your GL or something of that sort. This sheet could be connected externally to your systems, or you can import an Excel file to keep them updated.
I'd be interested as well in how others go about this too, especially with the more robust power of Spreadsheets. Let me know if you have any questions for me on the above, or need anything else. Thanks again and welcome to the Community!2Thank you Mike!
We will definitely go the route of maintaining one primary spreadsheet as a "single source" as that seems to be the best method to preserve data integrity and minimize duplicative work. A follow up question I have is this: is there a best practice during the roll-forward process to quickly produce a "shell document"? (all current period numbers throughout the document moving to a balance of 0 and prior period numbers populate while at the same time maintaining the integrity of all the source data throughout the primary spreadsheet). In our previous solution this was extremely time consuming and manual and someone from our team said they saw during a demonstration at Amplify a way to set things up so this can be done almost instantaneously. If possible, would like more details on how this is done. Thanks!
2HI Anthony, I would also like to hear the answer to your last question.
I am about to set up a Primary project, and in case you have not seen another post on this topic, here is a link to it, it gives more technical details:
Hopefully, after I link 10-K to the new Single Source, this will all work for a long time to come.
Sofia
1Hi Anthony, in response to your follow-up question, we have implemented a way to roll forward our single source spreadsheet to effectively do what you're saying - when we update our "Dates" tab, our footnotes all reset the current period to zero, and populate our prior period as-filed numbers.
We set up each footnote tab of our spreadsheet in essentially the same format: one table that mimics what your footnote table looks like, which is what is linked directly to your 10-Q or 10-K document, and then to the side of that, a "historical data" table where we keep our as-filed numbers for prior periods, which just gets updated each quarter to add the next current period while retaining the prior periods' columns. The current period's column would initially be set to zeroes, but then would be filled out by the footnote preparer (or it would be linked to our TB, which we sync into wDesk.) Then, we use INDEX(MATCH) formulas in the first table (the one directly linked to your filing document) to pull from your historical data table based on the column date and the line item. That way, when we change the date, the first table's column dates would update to the appropriate current periods and prior periods dates, and the table's INDEX(MATCH) formulas would pull the correct periods based on those updated dates. Thus, current periods update to zeroes, and prior periods update to your historical data. Hopefully that makes some sense.
A warning - Setting this up initially was a heavy lift, especially not having a dedicated resource to work on it 100% of the time. Once you get the general hang of it and create a few tabs using the same variations of your date INDEX(MATCH) formulas, it goes more quickly. But the value on the back end is almost immeasurable - we implemented this for our Q1 2019 10-Q and have been using it ever since, and have now done our first transition from Q to K format, which (so far, knock on wood) has worked flawlessly. We've cut our rollforward time significantly, and by being able to link a lot of data straight from the TB, updating numbers is a breeze.
My advice would be to work with your CSM - they might be able to put you in contact with some consultants who can help you get started, or show you some example templates. That is how we started, but then ran with it ourselves to set up our primary spreadsheet.
1Please sign in to leave a comment.
Comments
4 comments