Skip to main content
Showing results for 
Search instead for 
Did you mean: 

Find everything you need to get certified on Fabric—skills challenges, live sessions, exam prep, role guidance, and more. Get started

Frequent Visitor

Forecast V Actual Comparison Table

Hi Community,


I was looking for the best practice when deciding how to report on Actuals (from an accounting system exported into Excel) and Forecasts (written in excel spreadsheet system).


I have the data in PBI with the same fields in both tables (FORECASTPF and ACTUALPF) except obviously, one with actual $ values and one with forecasts $ values.


I understand creating a calculated table is the best way to join this information for reporting and calculating variances.

Can anyone, advise me of the required steps so i can easily work out the variances for different accounts, jobs and/or periods?


I was able to create a measure in my actuals table to calculate the forecast less actuals as shown below:

Forecast v Actual Model.PNG


1. But is there a better way to do this and create a single table for reporting on both Fact tables?

2. How do I link the Account Numbers, Names, Cashflow Group and Job number between to two? I am not sure how i should join these too tables to create one for analysis and reporting....?

3. Should i create new tables to hold the account numbers, names, jobs etc? to uniform the selection of these criteria?
Here is my table data so far.

Table StructuresTable Structures

Thanks again in advance for your help!

Microsoft Employee
Microsoft Employee

Hi @TheG,


In your scenario, since FORECASTPF table and ACTUALPF table almost have the same table structure, you needn't to use two tables. You can add then into one table with FORECAST and ACTUAL column. Select Combine > Merge Queries from the Home tab on the ribbon.



Charlie Liao


Thanks @v-caliao-msft


When i merge i dont get the complete matches probably as some account numbers are not in both tables...i guess i need to rework the table layout and split account numbers out, jobs, account names etc..







Not applicable

As noted above and based on the sample data screenshot, merging Actuals and Forecast could be problematic - you have multiple Actual records for July 2014, but only 1 Forecast record that I can see for that month.

HI @Anonymous yep i think i need to re-organise my tables design.



Not applicable

If this is more than a once-off analysis, I suggest stepping back briefly and deciding what you want to measure and visualise, and how flexible for future change it needs to be.  Then re-organise tables to suit - e.g. if you're only going to ever want monthly comparisons (not fortnightly, or drill down to individual Actual records), you might consider summarising Actual records to monthly granularity for your measures.  If you do decide on that, Charlie's @v-caliao-msftsuggestion about joining the tables could then make for a simpler model to analyse.

@Anonymous @v-caliao-msft


Thanks again guys for input...Yes i need to look at table design...i came up with this but i think the FORECASTPF table needs to be linked via ACCOUNTNUMBER to the ACTUAL the moment i have linked the FORECASTPF transaction date to DATEDIM.


I will have other FORECAST excel spreadsheets to add too.


Table Treev2.PNG


The structure above wont work that well for example if I want to compare the forecast [AccountNumber] against the Actual [AccountNumber]....How should i format the forecast table? The actual table is fine with this setup. I will have other forecast tables as mentioned like FORECASTCC, FORECASTSL, FORECASTEMW, etc....all with similar fields from an excel cashflow as shown in the FORECASTPF table above.


here is a sample of FORECAST spreadsheet i am using as the source. I have to manipulate a little to convert top row to headers and then unpivot the date/values.


Forecast Example.PNG


Currently, FORECASTPF is connected to JOBS (via Jobnumber) and DATEDIM (Calendar Date). I think it needs to be connected to AccountNumber but i cant get that relationship to connect.

Not applicable


This is getting more complex with extra columns for Job and Account, and different types of Forecast.  I'm not sure what CC and PF and SL and MW are?


From your original model, I agree that linking Account to Forecast seems to make sense.  You'll probably need to use a Cross Filter Direction of Single from your Account table to both Forecast and Actual to avoid an 'ambiguous relationship' error.  And the same may be required from Jobs as well.


Do you want to analyse Actual vs Forecast by both Job AND Account?






Hey steve, the forecast table is made up of Professional Fees (PF), Constructions Costs (CC), etc its for a property development. It will be in one spreadsheet actually but i split it for reporting purposes...The accountantlinkcode will indicate the group.


I am thinking I could merge the FORECAST and ACTUAL table into 1 fact table as advised before...The only unique fields in the forecast is the cashflow description (which i can do without if i can get the account name), transaction date and Value.


Yes there is a requirement for different jobs and account ranges...


I guess i have two fact tables ACCOUNTS from accounting system and FORECAST from Excel which have similar fields.



Not applicable

Given that Actuals (not "ACCOUNTS"?) from the accounting system and Forecast from Excel are imported separately, I'd suggest you start wiith:

  • Import Forecast and Actuals as separate fact tables
  • Extract out unique Account and Job dimensions, and create your Date dimension table as you've alrady done
  • Create relationships from your 3 x dimension lookup tables down to Actuals and Forecast, using "Single" for Cross Filter Direction as needed to avoid ambiguity
  • Use the FiscalMonth column on your Date table in measures to join related Actuals with their monthly Forecast

 You could collapse it all into just a couple of big table.  But doing the above steps up front should give you the foundations of a readable, maintainable model from which to most simply create measures and reports. There's also a good discussion by Matt Allington on creating Lookup/Dimension tables per above at thats work a read.




Not applicable

In some cases, you might prefer to keep them separate, at least as staging tables - e.g. update scenarios where you're adding new Actuals each month, checking in case Actuals for a new Account Number or Job Number have been added but no Forecast exists for it etc.

Helpful resources

Europe Fabric Conference

Europe’s largest Microsoft Fabric Community Conference

Join the community in Stockholm for expert Microsoft Fabric learning including a very exciting keynote from Arun Ulag, Corporate Vice President, Azure Data.

July 2024 Power BI Update

Power BI Monthly Update - July 2024

Check out the July 2024 Power BI update to learn about new features.

July Newsletter

Fabric Community Update - July 2024

Find out what's new and trending in the Fabric Community.