The core of your problem
This class represents a table with the above four columns.
A class does not represent a table. It represents a row of the table. One instance of this class is not able to represent more than one row of the table at the same time (and if it is, then you've wrongly designed your class).
A collection of this class would be a better representation of the table, leading us to the following usage of plural/singular:
IEnumerable<BudgetAmount> BudgetAmounts = new List<BudgetAmount>();
However, it was pointed out that since there are two amounts (dollar and unit) in the class, it doesn't make sense to name it as singular.
The developer is correct that one row contains two budget values.
However, the name of the class needs to represent the whole of the entity, not just two arbitrarily chosen columns of the entity.
If your developer is incapable of thinking of this entity as anything other than "the two budget values", then he's not understanding that what the entity represents (functionality) is not necessarily the same as what the entity contains (implementation).
If this is the case, it might be interesting to have your developer brush up on DDD. Even if you don't use DDD in your codebase, it very much teaches you the difference between your data (entities) and your domain (aggregates) and I think your developer is lacking this perspective.
The singular/plural distinction of a table versus a row is much more important than listing the columns of the row.
Note that this can be contextual. The singular/plural distinction of a table versus a row is much more important than listing the columns of the row in the data layer, but it might make more sense to list the budget values as a plural in the domain or user UI.
That is possible, and then you can make that distinction. However, this is likely going to cause naming confusion between layers and I suspect that it's not going to be worth going through all that trouble for.