The shipped config.yml in treasury/ and business-rian/ declares tax.balance.brackets with decimal threshold keys:
tax:
balance:
brackets:
0.00: 0.0
100000.00: 0.01
200000.00: 0.012
300000.00: 0.014
500000.00: 0.018
Bukkit/SnakeYAML treats . in a YAML mapping key as a path separator, so 100000.00 is parsed as a nested section (100000 → 00), not the scalar key "100000.00". BalanceTaxConfiguration.load() does getConfigurationSection("tax.balance.brackets").getKeys(false) → new BigDecimal(key) + getString(key, "0"), so it reads keys ["0","100000",...] with value "0" (the rate is a child section, not a string). The resulting bracket map is non-empty (integer parts parse), so it does not fall back to the correct hard-coded DEFAULT_BRACKETS.
Personal balance tax (Treasury) and firm balance tax (Business) brackets effectively resolve to a 0% rate with the shipped config — i.e. balance/wealth tax may be silently not applying in prod. This matches the earlier "why isn't the balance tax config working on SC?" report. Unit tests (BalanceTaxConfigurationBukkitCtorTest) only feed integer keys, so the mangling is untested.
config.yml bracket keys to integers in treasury/ and business-rian/:
brackets:
0: 0.0
100000: 0.01
200000: 0.012
300000: 0.014
500000: 0.018
config.yml (DC + SC) the same way.BalanceTaxConfiguration.load() defensive: detect mangled nested sections (or a key whose value isn't a scalar) and warn loudly / fall back to DEFAULT_BRACKETS rather than silently zeroing rates.Docs already WARN operators to use integer keys (economy-explorer PAR-163 / PR #20). Sibling bug in business-rian's mirrored BalanceTaxConfiguration. Surfaced by the docs-accuracy audit.