The sales manager walks out of the meeting saying the company will bring in a strong month. The accountant has already built the budget around a much more conservative figure. Both numbers belong to the same company, yet they come from completely different starting points. When the month closes, the gap is no surprise to anyone — because it happens every single month. For many small and mid-sized businesses in Turkey, this scene is painfully familiar.
BI software — short for business intelligence, meaning programs that pull data from different sources and turn it into readable reports — is one of the tools built to fix this problem. But simply buying a BI program and running reports is not enough. The real work is getting the sales forecast and the finance budget to stand on the same ground. Without that, even the best program will keep feeding two separate realities to two separate teams.
Why do these two worlds drift apart in the first place? Sales builds its forecast from customer conversations, order history, and gut feeling about the market. Finance builds its budget from last year’s numbers, fixed cost tables, and cash position. Both are doing their job correctly, but they are not starting from the same assumptions. One is asking ‘what will we sell’ and the other is asking ‘what money do we have.’ Both questions need to be asked at the same time, using the same base numbers.
This is what a shared assumption set means in practice. At the start of each month, the sales team and the finance team sit down together and agree on a small number of key figures: how many units are expected to sell in each product group, what the average unit price will be, and how long customer payments typically take to arrive. These numbers are written down, both sides agree, and the budget is built from them. The sales forecast starts from the same numbers. From that point on, both teams are speaking the same language.
This is exactly where the BI program earns its place. The software brings together order data coming from the sales side and payment and expense data coming from the accounting side, all on one screen. How are sales tracking through the month? Where do we stand against the budget? Which product line is running short? All of this becomes visible in a single report. Before this kind of program, making that comparison meant laying the sales ledger next to the accounting ledger by hand. The program does it automatically.
Building the monthly cycle is the most important step in making this work. The cycle runs like this: in the first week of the month, the shared assumption meeting takes place and the numbers are agreed. Those numbers go into the program. Throughout the month, actual sales and collections are entered as they happen. In the final week, the program produces a report comparing the forecast figures against the actual figures. That report becomes the starting point for the next month’s assumption meeting. The cycle repeats. Each month, the forecasts get a little closer to reality.
The most common obstacle when setting this up is resistance from the sales team. ‘Finance does not understand our business’ or ‘forecasts never work out anyway, so what is the point’ — these are the reactions that come up. The best way through this resistance is to start small. Pick one product group or one customer segment, run the cycle for that slice alone, and show the results. Once the numbers start to hold, both teams begin to trust the process. One more thing worth saying clearly: no matter how good the program is, the data inside it is only as good as what people put in. If sales orders are not entered on time, or accounting records are not kept current, the reports will mean nothing.
For a business owner thinking about setting this up, two questions are a useful starting point: who currently builds the sales forecast, and does finance even know what that number is? And can you see the forecast and the actual result side by side at month end? If the answer to either question is no, the first step is not buying software — it is getting both teams around the same table. A shared language comes first. The program comes second.
This article was originally written in Turkish by Gökhan MERCANOĞLU on June 3, 2002 and has been automatically translated into English and other languages using machine translation.