When switching between month and week view and comparing the projected balance at year end, you often see two different numbers, sometimes with a considerable gap. This is not a calculation error. Both views calculate correctly, but by different rules for which budgets count as "fulfilled" by payments that have already arrived.
Where the difference comes from
COMMITLY always matches actual payments and budgets within the selected period:
In the month view, the period is the month. A payment on the 5th can fulfill a budget dated the 20th of the same month.
In the week view, the period is the week. A payment from week 1 and a budget in week 3 belong to different periods and are not offset against each other.
That is why the difference always arises in the current month. Past months consist only of actuals in both views, future months only of budgets, so both views are identical there. Only the current month mixes actuals and plan, and that is exactly where the calculation paths diverge. Once it has arisen, the difference is carried forward unchanged to the end of the planning horizon. That is why it looks so large at year end although it comes from just a few weeks.
A typical example
For the current month, €100,000 of revenue is budgeted, dated in week 3. But the customer already pays in week 1. From week 2 onward:
Month view: The payment and the budget are in the same month, so the budget counts as fulfilled. The projection assumes €100,000 of revenue for the month. ✓
Week view: The payment is already included in the current account balance that the week starts with. From the week view's perspective, however, the budget in week 3 is still fully open and is added on top. The projection therefore contains the €100,000 twice and is too high by this amount.
The opposite case exists too: A budget from a week that has already passed and did not materialize is cut off by the week view (it starts with the current account balance and only looks forward), while the month view carries it along as open potential until the end of the month. In that case the month view is the higher one.
So neither view is across the board "the right one". The difference between them is rather a piece of information: In the current month, something went differently than planned.
What to do
The difference points to payments or budgets in the current month where plan and reality diverge in timing or substance. Depending on what actually happened:
A payment came earlier than planned (pull-forward effect).
Reduce the still-open budget in the later week by the amount already received. This removes the double counting in the week view.
A planned payment does not happen.
Switch to the month view (expired budgets are no longer visible in the week view), find the budget in the past period and delete it or set it to 0.
A planned payment is delayed.
Move the date of the budget to the current week or further into the future.
It was genuine additional business.
Then the higher projection is correct. Adjust your expectation instead, not the numbers. Artificially correcting away a deviation between the views would be cosmetics, not controlling.
After this clean-up, the views come very close to each other. An exact-to-the-cent match is not always possible by design as long as payments and their budgets fall into different weeks. It is reached at the latest once the affected weeks have passed.
Note: First check whether all transactions of the current month are mapped. Unmapped transactions also cause differences.
Why does COMMITLY not align this automatically?
Technically, the system could also offset payments and budgets automatically across week boundaries. COMMITLY deliberately refrains from doing so, because the system would have to guess: Was the early incoming payment a planned payment pulled forward (reduce the budget) or additional business (leave the budget as is)? Only someone who knows the business knows the answer. A system that changes budgets on its own here would smooth out the projection and in doing so erase exactly the signal that points you to the deviation. So: COMMITLY calculates transparently, you decide. The human stays in control, not the algorithm.