Level of effort and complexity are much better metrics for estimating work than lines of code (LOC). Furthermore, they can only be effectively estimated by the people who will be doing the actual work.
Using proxy metrics that don't map to actual costs is not a good way to plan a project or forecast a budget. Unless your company is actually paid for each line of code written, measuring LOC is probably not a useful way to develop the budget.
Assuming that there is some legitimate use for this data, the only ones who can tell you how that maps to budgeting is someone within your organization. You need to ask your management team to explain the process, though; no one outside your company can help you develop an internal budget, much less one based on a metric like LOC.
Can budgets be estimated this way?
No one outside your company can make business decisions for your organization. There may be a legitimate reason for this data, unlikely as it seems, so you need to ask your management team how this relates to budgeting. There is no substitute for active, internal communications!
As a general rule, using code base metrics for budgeting is an X/Y issue, where someone has likely decided to compare current code metrics against future projects to somehow arrive at headcount requirements, or to forecast a future project's productivity costs or potential runtime. However, even if you accept lines of code as a valid metric for productivity—something that is widely considered a bad idea in modern software development—this is unlikely to be useful in measuring the complexity, runtime, or level of effort of future projects. At best, you will end up with data that says something like:
Based on our current budget of M and our headcount of P, we can produce C lines of code per unit of time. Therefore, our projected costs for developing and maintaining projects slated for the next budget cycle will apply a fudge factor of F to our current budget for a total of
M * F.
At worst, you will end up with a bunch of useless or misleading data, and lot of failed expectations. If that's what the management team wants, go ahead and give it to them. However, the organization would be much better served by looking at the work projected for the next budget cycle, having the development and maintenance teams develop a rough level-of-effort estimate for it, and then using that data to baseline your budget forecasts.