Rule-based payouts, explained properly

Performance-based pay fails for boring reasons. Not because the idea is wrong, but because the rule was written in a document, calculated by hand, and interpreted differently by the two people looking at it.

The four shapes

A base amount is predictable and easy to approve, but it rewards showing up rather than results. A threshold bonus pays out once a number is crossed, which is simple but creates a cliff people will game. A milestone pays on delivery, which suits project work and badly suits ongoing work. A per-unit rate scales cleanly and is the only one that keeps working at volume.

Most teams end up with a base plus a per-unit rate, because it protects the person on a slow month and still rewards a good one.

What finance actually objects to

In our experience finance rarely objects to the model. They object to not knowing the ceiling. Every rule you write should have a stated maximum, even an implausibly high one, because an uncapped rule is an unbounded liability and no controller will approve it.

Calculate on every sync, not on a reminder

The last piece is timing. A rule that runs when someone remembers is a rule that generates disputes. Recalculate on every sync, show the working, and let the person being paid see the same figure you do before the invoice is raised.