## Code Analysis

### Bill-level amount discounts are not capped
`main/routes/bills.ts:2163-2184`
```ts
let discountAmount = 0;
if (type === 'percentage') {
  discountAmount = (bill.subtotal * Number(value)) / 100;
} else {
  discountAmount = Number(value);
}
discountAmount = Number(discountAmount.toFixed(decimals));

const discountedSubtotal = Math.max(0, bill.subtotal - discountAmount);
const taxRatio = bill.subtotal > 0 ? discountedSubtotal / bill.subtotal : 1;
```
For an amount discount, the requested value becomes `discountAmount` without a subtotal cap. The separate `Math.max` clamps only `discountedSubtotal`, so a request above the subtotal can leave the persisted discount larger than the amount used to derive the total.

### The uncapped value is persisted with the clamped total
`main/routes/bills.ts:2213-2228`
```ts
const preRoundTotal = discountedSubtotal + taxRollup.exclusiveTaxAmount
  + (bill.delivery_charge || 0) + (bill.packaging_charge || 0) + (bill.service_charge || 0);
const exactTotal = Number(preRoundTotal.toFixed(decimals));
const { total: newTotal, adjustment: newRoundOff } = applyPayableRounding(exactTotal, pack, currency);
const newBalance = Math.max(0, newTotal - (bill.paid_amount || 0));

UPDATE bills SET discount_amount = ?, ... total = ?, ... balance = ? ...
  .run(discountAmount, type, value, ..., newTotal, ..., newBalance, ...)
```
The update writes the uncapped `discountAmount` alongside the clamped `newTotal` and `newBalance`, allowing those financial fields to disagree.

### Order-level handling uses the expected cap
`main/routes/orders.ts:1243-1251`
```ts
if (discount_type === 'percentage') {
  discountAmount = (currentOrder.subtotal * discount_value) / 100;
} else {
  discountAmount = Math.min(discount_value, currentOrder.subtotal);
}
discountAmount = Number(discountAmount.toFixed(decimals));
```
The neighboring order-level implementation caps a flat discount to the subtotal before rounding, providing a concrete comparison for the bill-level path.

### Observed boundary results
The captured test evidence compared fresh bills with subtotal 120 after enabling amount discounts locally:
```text
# Amount 119: apply/get HTTP 200, discount 119, tax 0.07, total 1.07, balance 1.07;
# snapshot tax 0.07; cap and arithmetic consistency true.
# Amount 120: apply/get HTTP 200, discount 120, tax 0, total 0, balance 0;
# snapshot tax 0; cap and arithmetic consistency true.
# Amount 121: apply/get HTTP 200, discount 121, tax 0, total 0, balance 0;
# persisted discount exceeds subtotal (cap=false), and total arithmetic consistency
# against persisted discount is false. This is a boundary defect: request is accepted
# but discount_amount is not capped to subtotal.
```

### Result
The executed boundary comparison observed amount 121 being accepted and persisted against subtotal 120 while total and balance remained zero. The bill handler's uncapped amount assignment and separate subtotal clamp explain the inconsistent saved financial fields.

### Test context
The initial amount requests returned HTTP 400 while the local account was configured for percentage discounts. The run changed the local discount mode to allow amount discounts before repeating the boundary comparison; no application code was patched.