The review example starts B01 on hold, applies a fictional $80 approved rate, and recomputes the two-unit service amount as $160. It also keeps B02 held for missing delivery evidence. Changing the quantity clears the old calculation and requires another evidence check; no action creates or issues an invoice.
Define the request's evidence chain
Penn State's procedure distinguishes initiating-unit documentation from authorized invoice issuance, and describes checking completeness and approved rates. Those are useful reference concepts for an evidence handoff. Its specific systems, deadlines, and authority rules remain institution-specific. Penn State: Procedure FN2065
Use four linked inputs for the example's initial review:
| Input | What the preparer checks | Fictional B01 starting state |
|---|---|---|
| Customer identity | Which supplied customer the work belongs to | C01 identified in the example |
| Scope | Which service/version the request covers | S01 design-service scope |
| Delivered units | Evidence for completed work and quantity | D01 supplies two delivered units |
| Approved rate | Authority and applicability to this scope | Missing for the proposed $75/unit |
These identifiers are fictional placeholders, not documents we have inspected for a real customer. An operational request needs the actual references and versions behind them. Record the currency explicitly; this example uses USD.
Keep local tax, jurisdiction, account coding, terms, and other required fields on a separate applicable-requirements checklist. Unknown requirements are TO CONFIRM with the responsible team, not automatic defaults. Do not add zero tax or a standard payment term merely to complete the layout.
Hold B01 without discarding its history
The draft calculation is 2 × $75 = $150. Label both the rate and amount proposed. The missing approval blocks acceptance of that amount under this example's gate.
Create a hold row containing B01, the missing rate reference, a specific follow-up question, the actual assigned follow-up owner when known, and the response location. An appropriate question is: “Which approved rate record applies to the two design-service units under S01, and what effective scope/version does it cover?”
Leave owner and response evidence TO CONFIRM when absent. “Asked for approval” describes a request, not an approval received. Do not advance the status because a preparer has written the question.
Preserve the proposed $75 and $150 as the original draft state. Removing them would hide why the request was held and make a later price change difficult to explain. Mark superseded values clearly when the evidence changes.
Apply the supported rate and recompute the amount
For the next fictional state, a supplied record R02 authorizes $80 per unit for S01's design-service scope. Verify its applicability to the same customer/work basis rather than treating any approved rate as interchangeable.
| B01 revision | Rate state | Two-unit calculation | Preparation result |
|---|---|---|---|
| Initial draft | $75 proposed; approval absent | $150 proposed | Hold for rate support |
| After fictional R02 | $80 supported for S01 | $160 supported service amount | Rate question resolved; remaining checks and handoff still need evidence |
The new calculation is 2 × $80 = $160. Do not leave the old $150 next to the approved $80 rate. The supported service amount is not a fabricated invoice total including tax or other items that have not been established.
Record R02, its version and applicability, when its evidence was received, and who actually checked it. Keep the original proposal in the history, linked to the revised request. Do not assign a real person's verification or a timestamp that the record does not supply.
If the unit count changes later, invalidate the current calculation and recheck the delivered-unit evidence, scope, and rate applicability. Recomputing multiplication is necessary, but it does not establish that the additional unit was delivered or covered by the same authorization.
Review one request at a time
Select B01, leave the delivered units at two, and press Review amount. The initial rate is proposed, so $150 remains on hold. Apply the supplied R02 scenario and review again: the supported service amount is $160, with remaining requirements still to confirm. If you enter three units, the page holds the amount because D01 supports two. Restore the supported quantity before continuing.
Select B02 to inspect its missing delivery reference. An approved rate cannot establish delivered units. Keep its question separate from B01’s rate revision. Preparation, handoff, issuance, sending and payment each need their own record. Leave invoice number, issuance date and issuer acknowledgment blank until the authorized workflow supplies them.
Copy this prompt
Create an original preissuance billing-request review using two fictional requests, with a readable revision ledger and live arithmetic. B01 has customer C01, design-service scope S01 and delivery D01 for exactly two units. Its initial USD 75 per-unit rate is proposed and lacks approval. Display 2 × 75 = USD 150 as proposed and held for rate support. Provide an explicit Apply R02 scenario button: R02 authorizes USD 80 per unit for the same scope, producing USD 160 for the supported two units. Preserve the original 75/150 proposal as superseded history.
Give B01 a labeled unit input and a Review amount button. An input edit clears the old result. Reject blank, negative, fractional or excessive unit values. Any quantity other than the two supported by D01 remains held; arithmetic cannot prove extra delivery. B02 has no delivery reference, so selecting it must retain a separate hold even if R02 was applied to B01.
Show questions for missing rate or delivery evidence, plus TO CONFIRM placeholders for actual local requirements and receiving issuer. Keep acknowledgment, invoice number, issuance date, sending and payment unrecorded. The page is a review companion, not an invoice generator or approval system.
Return one complete self-contained HTML file with embedded CSS and JavaScript. Use native labeled controls with type="button" actions, readable text of at least 16px, strong contrast and visible focus. Make the layout responsive at 360px without horizontal scrolling. Keep supplied text literal. Use no remote dependencies or storage, and describe only actions the page actually performs.
Take the revised request to its reviewer
Keep the SOP, delivery record, scope and rate approval in your team’s established files. Send the authorized reviewer the supported revision and the unresolved questions through the existing process. For a discussion of the held and revised request, NOS can render a sanitized HTML review with the source references beside the amount. Begin that review with why $150 was superseded by $160, while keeping actual issuance evidence in the billing workflow.