Why PDP Moved Away from Manual Holdbacks for Defects

“Why would the contractor rush to fix defects if the payment for the work has already gone out?”

That question started a small but important financial change in PDP. The platform already had work items, contracts, and quality defects. What we needed was a mechanism that tied those three entities together through money: part of the payment to the contractor is withheld until all defects are fully resolved.

That’s how hold_percentage appeared — a percentage of the work value that the system calculates automatically. It looks like a one-field task. In practice, the main issue was not the field itself, but where it lives and which data it is calculated from.

The option on the table: a manual hold amount

The most obvious path was to give the user a “hold amount” field in the acceptance act or payment. There are defects — the manager enters how much should not be paid to the contractor. Once the defects are closed, the amount can be released.

On paper, this looks flexible. In the UI, it’s also straightforward: a field, validation against negative values, a hold status.

But for PDP, this approach quickly became a source of manual accounting. The hold amount started to exist separately from the contract and the scope of work. If the scope changes, the amount has to be recalculated. If different contracts have different rules, a person has to remember that. If later someone asks, “why was that exact amount withheld?”, the answer is not in the system, but in email threads or in the head of whoever entered the number.

There was another unpleasant detail: a manual amount does a poor job of distinguishing a financial rule from an ad hoc adjustment. Today it’s a hold for defects, tomorrow it’s a payment correction, the day after tomorrow it’s compensation. Everything ends up in one field, and the meaning is lost.

Why a percentage was better than a fixed amount

The requirement had a hard constraint: the hold had to be calculated from the work value and tied to the contract. So a fixed amount was not a good base model.

A percentage gives the system a solid anchor:

• the work value is already part of the calculations;
• the contract defines the context in which the rule applies;
• the hold amount is derived from the data instead of being entered separately;
• during verification, the calculation can be reconstructed: work volume, value, percentage.

The longest argument was not about the formula. The formula is short enough: work value multiplied by the hold percentage. The argument was about where to store it. If you place the percentage closer to the payment, it starts describing a specific transaction. If you tie it to the contract logic, it describes the rule for working with the contractor. For this task, we needed the second option.

So hold_percentage became part of a mechanism that works from the work scope and its contract link. The system calculates the amount that should be withheld from the contractor until the defects are closed.

What changed in the process

After hold_percentage was added, the hold stopped being a manual note. It became a calculated financial state.

There is work with a defined value. There is a contract link. There is a hold percentage. Based on those, PDP gets the amount that cannot be paid out to the contractor immediately until the defects are fully resolved.

This is especially important for work quality. A defect in the system is no longer just text or a status. It now has a financial consequence: part of the money stays on hold. It becomes more beneficial for the contractor to close issues faster, because until that happens, they do not receive the full amount for the completed work.

At the same time, we did not turn this into a penalty. A hold is part of the work value that is temporarily not paid out until a condition is met. The condition is clear: the defects must be fully resolved.

Where the trade-off is

A percentage-based mechanism is less “free” than a manual field. You can’t enter an arbitrary amount for each case and forget where it came from. But the calculation is repeatable and tied to the entities that already matter in PDP’s financial flow.

The trade-off was made in favor of traceability. If the hold amount is calculated automatically, it can be explained through the platform’s data: work volume, value, and contract link. That’s less convenient than a manual adjustment, but for money, boring is usually better.

Now defects affect not only the task list for the project, but also how the contractor’s payment is calculated. The next check in this scenario starts with a simple question: are all defects resolved, or should the hold still remain in the calculation?