In this note
You arrive to build an agent that will resolve invoice exceptions and post the corrections automatically. During the first walkthrough, the reviewer tells you every correction needs approval. The controls policy says the same thing. The project plan still says automatic posting.
You can build around the reviewer and hope the sponsor accepts it later. You can keep building the original promise and hope someone changes the policy. Both choices leave an unresolved decision inside the software.
I’d take the conflict to the person who can decide what the team may build. The hypothetical accounts-payable example below shows that conversation, while reviewers keep using their existing queue.
Keep the original brief intact
Save the original promise. Here, brief B-1 says, “Automatically resolve and post eligible invoice exceptions without a separate accounts-payable review.” Keep the author, version, and any associated scope or commercial commitment. Replacing it with “assist the review process” would hide the change you need someone to approve.
Then check who may post a correction and which data the team may use. “The CFO asked for it” cannot answer those questions if another person owns the control. An internal request needs the same checks as a customer engagement.
Keep the evidence in the approved store for this engagement, with its access and retention rules. Check that every record concerns this customer, workflow, and environment. A similar policy from another customer cannot settle this dispute.
Put the conflicting evidence side by side
| Record and claim class | Passage, scope, and limitation |
|---|---|
| B-1, sold brief | Automatic resolution and posting without separate review. Shows the inherited commitment; does not establish operational authority. |
| O-1, observed case 1042 | The reviewer inspected evidence, selected and approved a correction, then posted it in a separate step. Shows what happened in this case; does not establish frequency or permission. |
| P-8, policy-authorized | A designated reviewer must approve each covered correction before posting. Confirmed by the finance controls manager for this invoice population. |
| T-1, exact-build test | The teaching implementation rejects posting without separate valid approval. Establishes tested fixture behavior, not the behavior of the customer’s invoice platform. |
Keep the meeting focused on one question: may this service post a correction on its own? Show what changes if the answer is no. Review time comes back into the cost estimate, the completion event changes, and the plan and acceptance tests need updating.
Check the policy with its owner before presenting it. Does it still apply to these invoices? Was the observed case an exception? The test in the table ran against teaching software, so it cannot establish how the customer’s platform behaves. One observed approval can challenge the brief without proving a rule for every invoice.
Find the person who can decide this boundary
Several people have a say here. The finance transformation lead wants shorter cycle times. The accounts-payable lead knows the queue, and reviewers do the work. The service owner can agree what the team should deliver. The finance controls manager confirms the approval rule and checks that the design preserves it. Find out who holds each responsibility before asking for a decision.
The service owner can accept a smaller build without changing the approval policy. Waiving the policy would be a separate decision through its owner’s process. In this example, we’re asking to build inside the existing rule. A funding deadline cannot grant an exception.
If nobody agrees who can decide, record that gap and ask someone to resolve it. The delivery team can prepare the evidence while waiting, but cannot give itself approval rights to keep the schedule moving.
Propose work that can still help
Propose a smaller job: prepare corrections for domestic price-variance exceptions. The service would classify the exception, gather cited evidence, and stage the correction. A reviewer would still approve and post it. Missing or stale evidence would send it back to the manual queue. This proposal adds no other exception types or data access.
While the owner decides, reviewers keep using the existing queue and the team pauses the disputed posting work. Continue only observation or analysis already permitted. Ask before building a prototype that would need additional data access or could change records.
Check whether preparing a correction would help enough to justify its cost. Reviewers need time to inspect and reject bad proposals, so don’t keep the old estimate that assumed review would disappear. Leave the time and cost estimates open until someone tests them.
Record what happens under each answer
| Answer | Next move |
|---|---|
| Accept the bounded proposal | Record that the service owner accepts preparation and staging for these invoice exceptions, why, which evidence they used, and when. Record why they may decide this scope. Plan that work; obtain separate data, action, and release approvals. |
| Reject the proposal | Keep the decision and rationale. Stop this proposed slice or investigate an alternative the owner has requested; do not resume prohibited automatic posting. |
| Defer | Record the missing evidence or condition for reconsideration, its owner, and a review point. Keep the manual path. |
| No decision | Record that the conflict remains open. Continue only permitted discovery or pause the affected work. Silence does not accept the proposal. |
Write down what the person decided. “Everyone aligned” leaves the next engineer guessing. Keep the proposal, who decided, the evidence they used, and what remains excluded. Keep rejected and deferred proposals too, so the team doesn’t reopen them by accident.
Ask what would let the owner decide, and when. If review capacity is uncertain, arrange a permitted walkthrough with a reviewer. If the policy is disputed, ask its owner to confirm which invoices it covers. Put the action and responsible person in the delivery plan, including an unanswered request.
Agreement on scope lets the team plan the smaller build. Data access, tool permissions, release approval, and customer acceptance still need their own decisions. Keep those approvals separate from the scope agreement.
Update the work that depends on the change
After acceptance, link the original brief to the new decision and mark the old promise superseded. Update the plan, cost assumptions, and tests that depended on automatic posting. Review tool contracts and controls if the proposed actions changed. Leave unrelated documents alone.
The data contract may stay the same if the sources and permitted use haven’t changed. Check it rather than assuming. Record why each affected document changed or stayed put, with its owner. Revisit the decision when a policy changes or another invoice group is added.