Circular references and whether order of calculations is key for correct result

Hi All
Attached is a simple residual real estate appraisal I have built.
It includes circular references, which I know are not ideal, but I have 'Iterative calculations' ticked under options.
This appears to now be working, but I have had to really play around with the order in which calculations are made to make it work. Previously, and I cannot work out why my cell L75 was equaling my Gross Development Value in cell L25.
Could it be that unless calculations are undertaken in the correct order that the boxes in yellow will be incorrect?
I would really appreciate peoples comments on this and whether they think this appraisal now 'works' and is correct.
Many thanks.
Alex

As you note, it is working correctly now, so it is difficult to make any comments on the previous "error".

Could it be that unless calculations are undertaken in the correct order that the boxes in yellow will be incorrect?

Yes this is possible. There are many examples of numerical approximation algorithms that will converge when configured one way and diverge/oscillate/converge on the wrong answer when configured a different way. Exploring this requires a solid understanding of the math, algebra, and programming strategy you are using. I have not taken the time to completely reverse engineer the entire spreadsheet, so I am not familiar with what your sheet is doing.

If you can help us understand what this is doing so we don't need to reverse engineer the calculation the spreadsheet is doing, we can probably be of more help.

If it helps, while I have not fully reverse engineered the spreadsheet, here's what I do see (in a simplified, generic way). The spreadsheet has 3 sections -- one to compute GDV, one to compute costs, and a third section to compute loan amount. The GDV section is straightforward -- there are several inputs which are used to compute GDV. The costs and loan sections are more complicated and interrelated. Costs are calculated using GDV, loan amount, and various other inputs. Loan amount is calculated from GDV, costs, and other inputs. In a generic mathematical notation:
costs=f(GDV,loan)
loan=g(GDV,costs)
Seen like that, it appears to be some kind of "solve a system of simultaneous equations" problem. One strategy that some use for these is to guess a value for one of the quantities then compute the other quantity based on that guess which allows you to compute a new value for the first quantity which allows you to compute a new value for the second quantity which (and around and around we go). Eventually, you decide that you have found the solution to the problem or that you are not finding a solution. Of course, like any good system of equations problem, you can "check" the solution you get by plugging your final values into the equations to see if they are satisfied. This often works for problems like this.

But, if you go back to some of your early algebra classes, you will recall that there are several other strategies for solving systems of equations. Consider this tutorial: https://www.purplemath.com/modules/systlin1.htm The problems are obviously much simpler, but the techniques are often useful even for more complex real world problems.

I don't know if that helps, but if I were to continue to reverse engineer this, I would be looking to understand the details of the cost and loan sections until I had a firm grasp of how each section works on its own. Then understand how they are interrelated with the goal of understanding what the system of simultaneous equations looks like. Then I would be in a better position to talk about programming strategies for solving the equations.