For longer routes this quickly gets unreliable to work out on paper.
Could you elaborate on this, perhaps it's just a matter of going about it in the wrong way.
I don't think the total cost of the final solution would give much insight, beyond validating whether the cost that you use are also really used. For getting insight in how it works, I would propose a different approach (which I agree is quite labour intensive, but not difficult or unreliable, as far I can see).
The path finder makes single tile steps afaik, where it tries to avoid computing tiles that are not useful.
It's not hard to do this on paper too, if you don't care about avoiding computing useless tiles. (It reduces the amount of work, but the result doesn't change.)
Take a sheet of paper, and draw a grid of squares on them, large enough to hold a number. Mark the starting point with 0. Then, find all squares with an empty neighbour square, drop all squares that do not have the lowest possible number, then take any of the remaining squares. (that is, find a numbered square at the border of the numbered squares with the lowest possible value).
From that square, take the number (which is the cost to get there), for each movement direction, add the cost of the move to the neighbour (resulting in the cost to reach the neighbour through the chosen square), and check the computed value with the number at the neighbour (in the computed direction). If the neighbour has no number, or if it has a higher number, the computed value should be written in the neighbouring square.
Next, go back to "find all squares ..." to expand the next numbered square.
Do this until you have picked the destination square as square to use for checking its neighbours.
What you get at each square is the cost to reach that square. The real path is then found by starting from the destination, and repeatedly finding the (reachable) neighbour with the smallest number, thus reversing your way back the the start square.
The trick is thus not to compute a single route, but to compute smallest possible costs for all squares at the same time.
Being a retired OpenTTD developer does not mean I know what I am doing.