Clear cancellation and refund handling when an engagement changes.
ZoikoRum connects cancellation and refund handling to the governing contract, delivery state, payment state, approvals and dispute status. Applicable outcomes depend on the engagement terms, supported market and approved payment configuration.
Explore Enterprise Payment ControlsCancellation/refund rights, amounts, timing, provider roles, fees and availability vary by engagement, program and jurisdiction.
- Milestones affected
- M3, M4 · not started
- Accepted work
- M1, M2 · unchanged
- Refund relevance
- Review required
- Approval
- Budget owner
- Contract v4 executed[date]
- M2 accepted[date]
- Cancellation requestednow
Every outcome rests on
five governed inputs.
Contract
What governs the engagement?
Work
What has started, been delivered or accepted?
Money
What is funded, released, settled, paid out or held?
Authority
Who can request and approve the change?
Evidence
What record supports the outcome?
Seven layers,
kept separate.
Cancellation, release, payout and refund are different things. Select a layer.
Agreement
Future obligations / effective engagement state.
The authoritative contract/change reference and effective state — no legal interpretation beyond approved terms.
Six governed stages.
No surprises.
- 01
Request the change
Choose the affected engagement and explain what you want to stop or review.
Cancellation Request panel - 02
Evaluate current state
ZoikoRum reads the approved policy and authoritative contract, work, payment, approval and dispute states.
Evaluation summary - 03
Review the impact
See what would change before committing: obligations, milestones, money, payout and record effects.
Impact Preview - 04
Complete required authority
Where policy requires it, obtain approval or acknowledgement from the correct actor.
Approval / acknowledgement rail - 05
Execute approved actions
Authorized services update the engagement and process supported financial actions.
Execution status timeline - 06
Retain the record
A durable record of request, decision, state changes and payment references.
Outcome record / audit link
See the impact before you commit — and know who decides next.
Current state → proposed change →
projected impact.
Switch scenarios to see warnings. A stale preview can never authorize execution.
- Parties
- Buyer · Example Advisory LLC
- Contract
- v4
- Lifecycle
- In delivery
- Data as of
- [timestamp]
- Obligations
- M3, M4 remaining
- M1 · M2
- Accepted
- M3
- Not started
- Funding
- Confirmed
- Release
- M1, M2 released
- Payout
- M2 completed
- Hold / dispute
- None
- Request type
- Cancel + refund review
- Scope
- Remaining: M3, M4
- Effective point
- After M2 acceptance
No effect is implied until evaluation succeeds.
- Engagement
- Ends after M2
- Milestones affected
- M3, M4
- Refund relevance
- Review required
- Professional impact
- Remaining scope ends
- Approvals
- Budget owner
Structured fields.
No ambiguity.
Try it — validation, confirmation and the “submitted ≠ completed” distinction all work.
If contract, milestone, payment, hold, dispute or approval state changed, submit is blocked and the preview refreshes.
Request ID, status, next responsible actor and notifications — without invented timing.
Approved is not completed.
Both are shown.
- Relevance
- Whether a refund review applies to this cancellation.
- Not every cancellation creates a refund.
- Basis
- Governing policy/term/config reference and current payment state.
- No hidden support discretion.
- Amount
- Only an authoritative calculated/approved amount and currency.
- No invented percentages or estimates.
- Authorization
- Who or what approved the refund, and required approvals.
- Requester is not automatically authorizer.
- Execution
- Processing status and provider reference where applicable.
- Approved ≠ completed.
- Failure
- A clear recovery path and whether the approved outcome stays valid.
- No silent reversal on provider failure.
- Record
- Final transaction reference, decision event and audit link.
- Durable record.
A refund review is relevant; basis and current payment state are being assessed.
Symmetric state.
Appropriate privacy.
Scope requested, reason category, current status and next step.
Notification, affected scope, current status and permitted response or acknowledgement.
Authority, policy and exceptions —
on the record.
Policy profile
Organization-specific rules where supported, with name/version and evaluation result.
Authority
Requester, approver, budget owner and acceptance authority can be distinct.
Thresholds & routing
Only from the approved policy service — never hard-coded thresholds.
Exceptions
Permissioned, reasoned and badged — never a hidden override.
Separation of duties
High-impact actors cannot self-approve where policy forbids.
Evidence
Material decisions and changes retained in an audit timeline.
Reporting
Deep link to Audit & Reporting — no duplicate reporting engine.
Data as of
Every preview shows when its state was read.
Roles, permissions & separation of duties
- Buyer requester
- Can view
- Own engagement + material states
- Can request
- Yes, if permitted
- Approve / authorize
- Not by default
- Execute / administer
- No provider admin
- Buyer approver / budget owner
- Can view
- Engagement + decision packet
- Can request
- If policy allows
- Approve / authorize
- Yes, within authority
- Execute / administer
- No provider override
- Professional / firm member
- Can view
- Own professional-side states
- Can request
- Where supported
- Approve / authorize
- Acknowledge / respond only
- Execute / administer
- No buyer refund authorization
- Organization admin
- Can view
- Org-visible engagements per role
- Can request
- Per policy
- Approve / authorize
- Only if assigned authority
- Execute / administer
- Configuration if permitted
- Finance / payment ops
- Can view
- Payment/reference data within duty
- Can request
- Operational initiation
- Approve / authorize
- Only if explicitly assigned
- Execute / administer
- Execute/retry with audit
- Support
- Can view
- Minimum necessary view
- Can request
- Assist where allowed
- Approve / authorize
- No hidden financial authorization
- Execute / administer
- Recorded support actions only
- Auditor / viewer
- Can view
- Read-only evidence
- Can request
- No
- Approve / authorize
- No
- Execute / administer
- No
| Role | Can view | Can request | Approve / authorize | Execute / administer |
|---|---|---|---|---|
| Buyer requester | Own engagement + material states | Yes, if permitted | Not by default | No provider admin |
| Buyer approver / budget owner | Engagement + decision packet | If policy allows | Yes, within authority | No provider override |
| Professional / firm member | Own professional-side states | Where supported | Acknowledge / respond only | No buyer refund authorization |
| Organization admin | Org-visible engagements per role | Per policy | Only if assigned authority | Configuration if permitted |
| Finance / payment ops | Payment/reference data within duty | Operational initiation | Only if explicitly assigned | Execute/retry with audit |
| Support | Minimum necessary view | Assist where allowed | No hidden financial authorization | Recorded support actions only |
| Auditor / viewer | Read-only evidence | No | No | No |
The right owner
for every situation.
Contested delivery or acceptance
Request preserved, routed to dispute; resulting hold/resolution consumed.
Dispute Resolution
Open disputePayment execution or error
Payment reference and support route — never relabelled as a policy denial.
Payment Support
Get payment helpLegal entitlement questions
Approved term reference and product state — no legal advice.
Applicable terms
View termsFraud or safety concern
Routed to Trust & Safety with relevant evidence preserved.
Trust & Safety
Report a concernOrganization exception
An explicit exception/approval route where supported.
Policy / Approval Workflow
Request exceptionA durable record,
request to outcome.
Request record
Who requested, when, reason category, affected scope and exact object/version references.
Evaluation record
Policy/config version, authoritative state references, eligibility, requirements, blockers and evaluated timestamp.
Authorization record
Approvals, acknowledgements, exceptions and actor authority.
Execution record
Cancellation transition, refund instruction, provider/payment references, retry and failure events.
Outcome record
Final engagement, payment, payout and refund states; completion time; dispute/audit links.
Privacy controls
Field-level access, retention, jurisdiction/program restrictions and export permissions.
Clear before you commit
Visible to both sides
Recorded outcomes
Engage with clarity —
even when plans change.
Find the right professional, join as one, or govern engagements across your organization.
Cancellation/refund rights, amounts, timing, provider roles, fees and availability vary by engagement, program and jurisdiction. ZoikoRum does not provide legal advice or promise a refund.