Modified Purchase Requests

Short Description When you edit an approved PR, Hive9 checks the size of the change against a threshold to decide whether re-approval is needed. This article explains the logic.

What this article answers

  • What counts as a PR modification.
  • How the re-approval threshold works.
  • What the modified PR's pipeline looks like.

What counts as a modification

A PR is "modified" when its content changes after the initial approval:

  • A PR Line's amount is edited.
  • A PR Line is added.
  • A PR Line is removed.
  • The vendor changes.
  • The PR's dates shift.
  • A Line's link to a Tactic / Line Item changes.

Cosmetic edits (description text, internal notes) typically don't trigger re-approval. The line-level changes that affect dollar amounts or attribution are what matter.

The re-approval threshold

Your instance has a modification threshold configured by your admin. The threshold is delta-based — it asks "how much did the PR change?"

The check happens automatically on save. If the change is within threshold, the PR remains in its existing approval state. If the change exceeds the threshold, Hive9 puts the PR back into approval.

Common threshold patterns

  • Percentage threshold — re-approval if the change is more than X% of the original PR total.
  • Absolute threshold — re-approval if the change exceeds a fixed dollar amount.
  • Combined threshold — whichever is reached first.

Ask your admin or finance team what's configured for your instance.

[SCREENSHOT NEEDED — PR Inspection Window showing pre- and post-modification states]

What happens when re-approval triggers

When a modification triggers re-approval:

  1. The PR's status moves to Pending Approval (or your instance's equivalent).
  2. The Approval Tracker regenerates based on the current workflow.
  3. Approvers are notified per the workflow's notification rules.
  4. The PR can't be acted upon (no transactions, no further edits without further re-approval) until the pipeline completes.

Approvers' view of a modified PR

When approvers open a modified PR:

  • The Approval Tracker reflects the new approval cycle.
  • The PR Lines show their current state (post-modification).
  • Approvers may want to compare against the pre-modification state — the audit log captures both, accessible from the PR or the global audit logs.

How to plan a modification

If you know you need to edit a PR:

  1. Estimate the delta first. Will the change be under or over your instance's threshold?
  2. Bundle changes into one save. Each save can potentially re-trigger the threshold check. Saving multiple times can cascade.
  3. Notify approvers if you expect re-approval, especially if timing is tight.
  4. Document the reason in the PR's description or notes — approvers will appreciate context.

Common questions

How do I see what the threshold is for my instance? Ask your admin. The threshold is set in the Purchase Request Configuration and isn't directly visible to end-users.

Can I bypass re-approval as an admin? No — modifications above threshold trigger re-approval for everyone, including admins. The fix is to either keep changes under threshold or to complete the re-approval cycle.

What if I made a typo in a PR that was already approved? Truly cosmetic typos (description text) usually don't trigger re-approval. If it's a typo in an amount, that's a modification and will probably trigger re-approval — proceed through the cycle.

Will the modification trigger Tactic re-approval too? PRs and Tactics have separate workflows. Modifying a PR doesn't directly re-trigger Tactic approval, unless the change cascades back to a Line Item that crosses a tactic-level threshold.

Related articles

Was this article helpful?

Comments

0 comments

Please sign in to leave a comment.