The primary point of SCRUM (and other iterative or agile approaches) is that it is not known what work and how much of it is required to "finish" the project. At any point during the project new tasks can be added, expanded or removed based on feedback from the customer. This is why SCRUM and other agile methodologies opt into making working software every iteration to give customer sense of progress instead of "traditional" we are x% done when x% of [budget is spent] / [planned time is spent] metrics.
This is problem for any form of predictive metrics, like estimated total cost or time needed, because you have no fleeting idea how much work actually needs to be done. There are ways to guess, but the more complex and big the project gets, the more uncertainty you get. And I don't know if your customer will be fine with estimation of 1year +- 9 months and with related total cost.
If you really need to estimate total cost and time spent, I would get rid of SCRUM and go for more traditional approach where you try to guesstimate all tasks needed to finish the project and how much work is required to finish them. You at least get some semblance of certainty that your guesstimations might be correct.