When a sales based billing rule calculates unexpectedly for quick-service restaurants

A sales rule can look correctly configured while using the wrong model, scope, date, or source values. Reproduce the result with one representative period, inspect the rule version and inputs, and preserve the previous version while the discrepancy is investigated.

Find your symptom ↓

Choose the symptom you can observe

Open the matching case. Check the existing state before changing a record or repeating an action.

The calculated amount is higher or lower than the expected result.

Check first

  1. Confirm the calculation model, rate or tier, source sales value, and rounding basis.
  2. Compare the rule's effective dates with the reporting period being tested.
  3. Check whether a service, class, adjustment, or exclusion changed the eligible base.

Next action

Reconcile the representative calculation from source value to output, then correct the rule version or source mapping that explains the difference. Keep the existing version available for comparison instead of editing history in place.

Confirm the result

A new preview or test period produces the expected amount and records the model, inputs, effective version, and reviewer.

The rule applies to locations or services it should exclude.

Check first

  1. Review the selected franchise, service, class, and availability scope on the saved version.
  2. Compare one included and one excluded record to see which selection caused eligibility.
  3. Check whether the reporting period falls inside the rule's effective dates.

Next action

Correct the target scope in a new rule version and preview both boundary records before activation. Do not remove source reports or manually alter resulting amounts to compensate for an incorrect target.

Confirm the result

The preview includes only the intended targets and the saved version explains its effective scope and exclusion behavior.

A saved rule does not affect the expected future cycle.

Check first

  1. Confirm the rule version is active or available for the selected cycle.
  2. Compare the effective start and end dates with the cycle's reporting period.
  3. Check whether another active version has priority for the same scope.

Next action

Resolve the version or date precedence with the rule owner, then preview the intended cycle using the version that should govern it. Leave the old version intact and document any transition boundary.

Confirm the result

The cycle preview identifies the governing rule version and the expected target set before any billing work proceeds.

The rule is ready on paper but cannot route its billing result.

Check first

  1. Confirm the selected payment destination belongs to the organization and is in a usable state.
  2. Check whether the destination is assigned to this rule version or only to another rule.
  3. Review any readiness or verification message attached to the destination.

Next action

Route the destination problem to its owner, then return to the rule and recheck its readiness. Do not activate a calculation rule with an unresolved destination just because its math previews correctly.

Confirm the result

The active rule names a ready destination and the readiness check no longer reports a routing blocker for the intended scope.

Prepare a useful escalation

  • Include the rule version, calculation model, effective dates, target scope, representative source value, and unexpected output.
  • Provide one included and one excluded example when the problem is scope-related.
  • Ask the rule owner to approve any change that alters a future billing calculation or destination.

Reference the relevant record instead of copying credentials or unrelated personal information into the handoff.

Capture your findings

Entries stay in this page and are not sent to Granite. Download a copy before leaving.

Continue in Granite

Granite's sales-based billing rules connect versioned configuration to eligible reporting periods and invoice review.