Legal
Default / Nonpayment Terms
These Default / Nonpayment Terms describe the default and nonpayment workflow for failed payments, unresolved invoices, disputes, chargebacks, payment-method failure, customer delay, service pause, suspension, final default review, settlement, write-off, restoration, termination review, ownership-transfer withholding, and related records for the applicable Sites customer relationship.
1. Role Of These Terms
1.1 Default framework. These Terms describe the workflow for failed payments, unresolved invoices, disputes, chargebacks, payment-method failure, service pause, suspension, final default review, settlement, write-off, restoration, termination review, ownership-transfer withholding, and default records.
1.2 Relationship to Order Form. The Order Form controls customer-specific price, plan, term, recurring amount, add-ons, payment entries, and customer-specific commercial facts.
1.3 Relationship to payment documents. The Subscription / Payment Terms and Payment Authorization control the Signup Payment, Recurring Billing, saved Payment Method, Authorized Charges, refund and credit review, customer portal limits, and payment records.
1.4 Relationship to Ownership Transfer Terms. The Ownership Transfer Terms control transfer eligibility, Account Standing, platform handoff, transfer withholding, and transfer exceptions.
1.5 Staged remedy framework. These Terms use a staged, proportional, records-backed default workflow. They do not make acceleration, liquidated damages, automatic remaining-term collection, immediate termination, or aggressive collections the standard remedy.
1.6 No public-material expansion. Pricing pages, sales discussions, proposals, dashboard messages, Help Center articles, checkout screens, onboarding flows, support messages, portal labels, invoice labels, and processor-generated notices do not expand default remedies, payment obligations, cancellation limits, collection rights, transfer holds, fees, interest, or customer duties unless the expanded term is included in the signed Order Form, signed amendment, approved default-resolution record, or approved settlement record.
1.7 No hidden remedy economics. Any payment amount, cure deadline, default-resolution amount, restoration amount, settlement amount, fee, tax amount, credit, write-off, collection referral, remaining-term amount, or transfer-withholding consequence must be supported by the signed documents and a customer or account record. These Terms do not approve hidden charges, hidden cancellation penalties, hidden early-termination charges, or unrecorded remedy economics.
1.8 Issue-specific priority. These Terms control default classification, Notice and Cure Period workflow, Service Pause, Suspension, Final Default Review, restoration, settlement, write-off, collections review, and default records. The Order Form controls customer-specific amounts and commercial entries. The Subscription / Payment Terms control payment lifecycle, cancellation and refund review, recurring billing trigger, payment processor alignment, and payment records. The Payment Authorization controls authorization categories, saved-payment-method consent, and payment-record authorization. The Ownership Transfer Terms control transfer eligibility, transfer package, transfer withholding, and transfer exceptions. These Terms do not decide tax treatment, accounting treatment, refund outcome, cancellation outcome, payment authorization, transfer ownership, or customer message wording by themselves.
2. Defined Default Terms
2.1 "Failed Payment" means any declined charge, unpaid invoice, expired payment method, payment reversal, payment-processing failure, or other unpaid amount due under the signed documents after payment review confirms actual unpaid status. A good-faith billing inquiry, plausible duplicate-charge issue, suspected erroneous charge, customer support request, or documented good-faith dispute is not a default-triggering Failed Payment unless the payment review process confirms unpaid status, default status, fraud or security risk, chargeback abuse, or another signed-document default trigger.
2.2 "Past-Due Amount" means an amount due and unpaid after the applicable invoice due date, payment attempt, retry process, or payment deadline.
2.3 "Default Event" means a payment, access, misuse, unauthorized use, abandonment, or agreement violation event described in Section 3.
2.4 "Notice" means a payment or default communication sent or recorded by Sites through email, dashboard, invoice, processor workflow, support channel, or another documented method.
2.5 "Cure Period" means the payment-resolution period stated in the Order Form, payment notice, or other applicable payment record after Notice. If no customer-specific period is stated, the Cure Period is the period stated in the applicable payment notice, Order Form, or accepted customer order record after payment notice.
2.6 "Service Pause" means a temporary pause of non-critical services while an unresolved Default Event is reviewed or cured.
2.7 "Suspension" means a broader restriction of services after unresolved default, Notice, and Cure Period workflow.
2.8 "Final Default Review" means the manual review stage after unresolved default to decide restoration, settlement, write-off, termination review, transfer hold, or another recorded resolution.
2.9 "Account Standing" means all amounts due are paid or otherwise resolved under an approved payment, customer-visible settlement, customer-visible waiver or credit, or restoration record, with no unresolved payment default, dispute, chargeback, suspension condition, or transfer-hold issue. An accounting write-off alone does not create Account Standing unless the approved Default Resolution Record expressly states the customer-visible effect, transfer effect, collection effect, and account-standing result.
2.10 "Default Resolution Record" means the record identifying the Default Event, amount and status, signed-document basis, customer notices, Cure Period deadline, payment processor status, service impact, tax and accounting flags, restoration conditions, transfer impact, approval owner, and final outcome.
2.11 "Cancellation Resolution Review" has the meaning stated in the Subscription / Payment Terms. It is the review process triggered by a cancellation request, cancellation-related communication, Authorization Revocation, portal event, processor event, or post-cancellation attempted charge to decide automatic-billing status, open invoice handling, refund or credit routing, default routing, transfer impact, and customer communication.
2.12 "Authorization Revocation" has the meaning stated in the Payment Authorization. Authorization Revocation is not an automatic Default Event; it triggers cancellation-resolution review, payment-method update review, open-invoice review, and default classification only if the signed documents and payment records confirm actual unpaid status, signed-document default, fraud or security risk, chargeback abuse, or another default trigger.
2.13 "Good-Faith Dispute Hold" means a temporary hold category for a plausible billing error, duplicate-charge report, unauthorized-charge report, processor-error report, service dispute, privacy or security concern, accessibility concern, legal concern, or documented good-faith dispute before ordinary default consequences are applied to the disputed amount.
2.14 "Urgent Restriction Record" means the record supporting a shortened or bypassed Cure Period for fraud, security, privacy, excluded-use, unlawful, unauthorized-access, documented chargeback abuse, documented processor risk, documented platform risk, or another documented urgent event before or promptly after action.
2.15 "Customer-Visible Notice Record" means a record of the notice surface or channel, notice version or template ID if used, document basis, amount or status stated, requested cure action, cure deadline, consequences stated, support route, and record owner.
2.16 "Final Notice" means a customer-visible notice, if required by the applicable workflow, sent before Suspension, termination review, collection review, transfer-hold escalation, or final default closure.
3. Default Events
Default Events include the following events when they are supported by the signed documents, payment records, customer communications, or applicable service records:
Failed Payment not cured after retry or dunning and Notice;
Past-Due Amount not paid during the Cure Period;
failure to maintain a valid authorized Payment Method after payment review confirms the issue is not merely Authorization Revocation, cancellation intake, customer-requested replacement, processor error, or unresolved good-faith dispute;
disputed payment, chargeback, reversal, or payment processor inquiry not resolved after triage confirms unpaid status, default status, processor risk, fraud or security risk, or chargeback abuse;
documented refund abuse, documented chargeback abuse, payment fraud, or unauthorized payment conduct;
material customer delay, unresponsiveness, or abandonment after required notices;
misuse of services, platform access, credentials, dashboard access, account access, or Sites systems that materially affects performance, security, payment status, platform access, or signed-document obligations;
excluded-use activity or request that Sites cannot support under the signed documents or applicable intake rules;
unauthorized copying, use, transfer, scraping, reverse engineering, or disclosure of Sites Assets where prohibited by the signed documents;
unauthorized removal or restriction of Sites access needed to provide active-term services;
unresolved violation of signed scope, payment, migration, ownership-transfer, customer-responsibility, access, or platform terms;
activity that creates security, privacy, legal, platform, payment, or customer-data risk and requires payment/default, access, or urgent restriction review.
3.1 Payment failure classification. Each payment failure should be classified before retry, Notice, Cure Period, service impact, default review, or transfer hold. The classification should identify whether the event is a signup authorization issue, processing failure, saved-method failure, card decline, bank return, authentication issue, processor risk hold, Authorization Revocation, manual invoice nonpayment, post-cancellation attempted charge, chargeback, or dispute.
3.2 Cancellation and default boundary. Cancellation requests, portal cancellation events, Authorization Revocation, manual processor cancellation, collection-setting changes, card-network inquiries, bank inquiries, post-cancellation attempted charges, and open invoices after cancellation request must be routed through Cancellation Resolution Review before they are treated as default consequences.
3.3 Good-faith dispute boundary. A good-faith billing inquiry, plausible duplicate charge, unauthorized-charge report, processor-error report, or documented service dispute must be triaged before ordinary default consequences are applied to the disputed amount, unless urgent fraud, security, processor, or platform-risk conditions apply.
4. Staged Nonpayment Workflow
4.1 Standard sequence. The standard nonpayment workflow is:
Payment fails or becomes past due.
Stripe or another approved processor retry or dunning begins if configured.
Sites creates or updates an failed-payment record.
Notice is sent or recorded.
Cure Period begins.
If unresolved, Sites may place non-critical services in Service Pause.
If still unresolved and required by the applicable workflow, Final Notice is sent or recorded before Suspension or final remedy escalation.
If still unresolved, Sites may place affected services in Suspension.
Final Default Review occurs.
Sites records restoration, settlement, write-off, termination review, transfer hold, or another resolution.
Ownership transfer remains subject to the Ownership Transfer Terms and may be withheld while transfer eligibility conditions, Account Standing, or written settlement-transfer exception requirements remain unsatisfied.
4.2 Exact timing. Exact retry schedule, Notice timing, Cure Period length, pause timing, suspension timing, and final review timing must match the Order Form, Subscription / Payment Terms, Payment Authorization, payment processor settings where used, and customer notice workflow.
4.3 Manual review. Suspension, termination review, settlement, write-off, transfer exception, collection referral, or final default closure requires manual review and a record.
4.4 Processor settings do not control document status. Stripe or another processor may run retries, invoice updates, portal actions, reminders, dispute workflows, or payment-status changes. Processor settings, emails, labels, statuses, or automations do not replace the signed documents, Customer-Visible Notice Record, manual review, or Default Resolution Record.
4.5 No automatic escalation. A failed retry, dispute, chargeback, portal action, customer delay, or unpaid invoice does not automatically trigger suspension, termination, collections, ownership-transfer withholding, settlement demand, remaining-term amount, or another final remedy without the required record and review, except for temporary urgent restrictions for fraud, security, privacy, excluded-use, unlawful, or platform-risk events.
4.6 Customer-type and location workflow. If a customer-type, customer-location, payment-rail, or transaction-specific rule requires a particular online cancellation, payment update, notice, dispute, cure, or support path, Sites must use an approved workflow for that customer or transaction type. Portal actions and processor settings still do not override the signed documents unless the signed documents or a written resolution record expressly provide otherwise.
5. Notice And Cure
5.1 Notice record. Notice records must identify:
customer or account reference;
invoice or payment reference;
amount;
due date;
failed payment date or default date;
Notice date;
Notice method;
recipient;
Default Event;
requested cure action;
Cure Period start and deadline;
document basis;
account status after Notice.
5.2 Customer-visible notice basis. A Notice record must identify the customer-visible notice surface or channel, notice version or template ID if used, document basis, amount or status stated, requested cure action, cure deadline, consequences stated, support route, and record owner.
5.3 Cure action. Cure may require payment, Payment Method update, dispute withdrawal or resolution, account correction, access restoration, customer response, content or access delivery, settlement approval, or another action listed in the Notice.
5.4 Urgent events. Sites may shorten or bypass ordinary Cure Period steps only for documented fraud, security risk, privacy risk, documented chargeback abuse, excluded-use activity, unauthorized access, platform-risk conditions, unlawful conduct, documented processor risk, or another documented urgent event.
5.5 Urgent action record. Any shortened or bypassed Cure Period must be recorded with the urgent risk, affected systems, data, accounts, temporary action taken, customer notice if feasible, review owner, restoration conditions, and why ordinary notice and cure timing was not used.
5.6 Urgent action limits. Urgent action must be limited to the affected service, account, credential, data flow, payment rail, or platform risk to the extent feasible. The record must identify post-action notice timing, preserved payment or default notice access, preserved privacy, security, or offboarding route where feasible, escalation owner, and restoration path.
5.7 No waiver. Sending Notice, allowing a Cure Period, accepting partial payment, providing temporary access, or delaying Service Pause does not waive Sites' rights, payment obligations, default remedies, ownership-transfer conditions, or later enforcement unless the written resolution record expressly says so.
6. Service Pause
6.1 Service Pause trigger. If a Default Event remains unresolved after Notice and Cure Period, Sites may pause non-critical services.
6.2 Services that may be paused. Service Pause may apply to:
non-critical updates;
non-critical support;
new Managed Time work;
new Growth Time work;
new migration work not needed to preserve customer data;
nonessential dashboard features, provided that billing and default notice access remains available through dashboard, email, invoice notice, or another recorded notice method;
non-critical integrations;
add-ons;
reporting;
new scope requests;
launch or Move-in Complete work if the default affects readiness or payment status.
6.3 Services and duties preserved. During Service Pause, Sites must preserve reasonable records, security controls, access-control duties, and offboarding duties required by the signed documents and applicable workflow.
6.4 Services not paused without review. Service Pause must not block customer access to invoices, payment-status information, default notices, export or handoff information needed for required offboarding, security communications, privacy or security incident communications, or legally sensitive customer communications unless an urgent security, privacy, fraud, excluded-use, unlawful, or platform-risk record supports the restriction.
6.5 Customer delay link. If Service Pause is caused by customer delay or failure to provide access, content, approvals, payment, or response, Sites must link the Service Pause record to the customer-delay record.
7. Suspension
7.1 Suspension trigger. If a Default Event remains unresolved after Notice, Cure Period, and Service Pause when applicable, Sites may suspend affected services.
7.2 Suspension record. Suspension must be recorded with:
suspension date;
reason;
Default Event;
Notice history;
Cure Period status;
payment status;
account status;
services affected;
customer communications;
restoration conditions;
ownership-transfer impact.
7.3 Suspension boundaries. Suspension does not transfer ownership to Customer, waive unpaid amounts, waive customer obligations, approve cancellation, approve refund or credit treatment, or create transfer eligibility.
7.4 Security and data. Suspension must not be used to create avoidable security, privacy, credential, customer-data, or platform-risk problems. Any data, access, or offboarding duties must be handled under the applicable access and offboarding process.
7.5 Suspension evidence. Suspension may not be used as support for collection, transfer withholding, termination review, status message, or final default closure unless the Suspension record is complete, customer-visible notice was recorded where feasible, and manual review confirms the affected services and restoration conditions.
7.6 Status message limits. No dashboard label, Help Center article, support macro, invoice note, processor email, portal label, or customer message may describe an account as terminated, in collections, transfer-ineligible, legally defaulted, or ownership-forfeited unless that status is supported by the applicable Default Resolution Record and customer-visible wording record.
8. Final Default Review
8.1 Final review trigger. Final Default Review occurs if the Default Event remains unresolved after the applicable Notice, Cure Period, Service Pause, and Suspension workflow, or if the Default Event requires manual escalation.
8.2 Final review options. Final Default Review may result in:
restoration after payment or cure;
Payment Method update and restoration;
service credit or credit adjustment;
refund review;
dispute or chargeback response;
settlement;
write-off;
termination review;
transfer withholding;
settlement-transfer exception;
customer-service accommodation;
referral for collections if separately approved for the specific matter.
8.3 Final review record. The final review record must identify the default history, payment status, customer communications, work status, service status, proposed outcome, approval owner, accounting category, customer notice, and ownership-transfer impact.
8.4 Final review neutrality. Final Default Review does not decide enforceability, collections law, tax treatment, book accounting treatment, bad-debt treatment, refund or credit accounting, sales-tax treatment, or chargeback response legality.
9. Restoration
9.1 Restoration conditions. Restoration after default requires:
payment of past-due amounts or approved payment resolution;
valid Payment Method update if needed;
dispute or chargeback resolution if applicable;
customer response or access cure if applicable;
default-status update;
service restoration record.
9.2 Restoration scope. Restoration resumes only the services identified in the restoration record. It does not automatically restore missed timelines, waive delays, reverse suspension history, remove default records, or approve ownership transfer.
9.3 Timeline effects. Launch targets, migration timelines, support targets, Move-in Complete timing, and recurring service timelines may be paused, extended, reset, or reforecast after restoration depending on the default, customer delay, platform status, and service records.
9.4 Restoration accounting and transfer status. Restoration does not by itself decide tax treatment, accounting treatment, write-off reversal, sales-tax reversal, or ownership-transfer eligibility. The restoration record must update accounting and transfer status where affected.
10. Disputes, Chargebacks, Refunds, Credits, And Reversals
10.1 Dispute or chargeback event. A dispute, chargeback, reversal, or processor inquiry creates a payment-status and evidence-record event.
10.2 Evidence record. Sites must maintain records for:
dispute or chargeback reference;
customer account reference;
payment or invoice reference;
Order Form reference;
Payment Authorization reference;
checkout acknowledgment record;
onboarding or work record;
launch approval record if applicable;
customer communications;
refund or credit review record if any;
evidence submission status;
outcome;
accounting treatment;
ownership-transfer impact.
10.3 Service impact during dispute. If a dispute, chargeback, reversal, or processor inquiry creates actual unpaid status, unresolved nonpayment, documented fraud concern, documented security risk, documented platform risk, documented chargeback abuse, or a default condition after triage, Sites may pause or suspend affected services under these Terms while preserving reasonable records and security obligations. A good-faith billing inquiry, plausible duplicate-charge issue, or documented good-faith dispute must be triaged before ordinary service impact unless urgent fraud, security, processor, or platform-risk conditions apply.
10.4 Refund and credit review. Refund, credit, settlement, and make-good decisions are governed by the Subscription / Payment Terms and must be documented with reason codes, approval owner, payment action ID if any, accounting category, and account-status impact.
10.5 Good-faith dispute triage. A documented good-faith billing dispute must be triaged separately from fraud, chargeback abuse, abandonment, or nonresponsive default. The record must identify disputed amount, undisputed amount if any, customer position, Sites position, evidence, temporary service status, cure or status deadline, and resolution owner.
10.6 No dispute-retaliation posture. Service Pause, Suspension, transfer hold, or default closure must not be framed as retaliation for raising a good-faith billing, service, privacy, security, accessibility, or legal concern. The record must tie the action to payment status, access or security risk, platform risk, customer delay, signed-document basis, or another documented operational reason.
10.7 Duplicate, mistaken, unauthorized, or processor-error hold. If Customer plausibly reports a duplicate charge, mistaken charge, unauthorized charge, processor-confirmed error, or payment-method misuse, Sites must place ordinary default, suspension, transfer hold, collections, and post-cancellation charge action on review hold for the disputed amount until the payment review identifies the issue as resolved, unpaid, fraudulent, abusive, or otherwise default-triggering under the signed documents.
10.8 Disputed and undisputed amount handling. During Good-Faith Dispute Hold, ordinary default consequences for the disputed amount must be held unless urgent fraud, security, processor, or platform-risk conditions apply. If an undisputed amount remains unpaid, Sites must separately record the undisputed amount, notice and cure path, service-impact path, and customer communication before applying default consequences to that undisputed amount.
11. Customer Delay, Abandonment, And Access Failure
11.1 Customer delay events. Customer delay events include failure to provide content, access, approvals, domain or DNS readiness, platform access, migration decisions, payment information, launch approval, security response, or required customer input.
11.2 Delay record. Customer delay records must identify the requested action, request date, due date, customer response, affected timeline, affected services, payment impact if any, and next action.
11.3 Abandonment review. Extended unresponsiveness or repeated customer delay may trigger abandoned-project review, Service Pause, payment review, default review, or scope reforecasting.
11.4 No automatic refund. Customer delay, unresponsiveness, or abandonment does not automatically make the Signup Payment refundable, waive amounts due, shorten the term, or create ownership-transfer eligibility.
11.5 Delay and default evidence. Customer delay or abandonment may not support Service Pause, Suspension, default closure, transfer withholding, or payment consequences unless the delay record identifies requested action, request date, deadline if any, missed dependency, customer communications, affected work, affected payment or default item if any, and next-action owner.
11.6 Objective work and capacity evidence. If customer delay, abandonment, or nonresponse is used to support no-credit, partial-credit, settlement, default, or transfer-hold treatment, the record must include dated objective evidence such as scheduling record, onboarding record, platform or workspace setup record, access request, migration inventory, content review, planning work, work log, or customer communication.
11.7 Delay review factors. Customer delay or abandonment should not support default closure, no-credit treatment, suspension, transfer withholding, or settlement demand unless the record also checks Sites-side delay, Sites inability to serve, regulated-use or unsupported-use issue, missing Sites dependency, refund or credit exception review, required notice cadence, requested customer action, deadline, affected work, affected payment item, and next-action owner.
12. Ownership Transfer Withholding
12.1 Transfer hold. Sites may withhold ownership transfer, Framer or project handoff, domain or DNS handoff support, analytics or Search Console handoff, forms, CMS, integration handoff, and other transfer package steps if payment, term, default, settlement, chargeback, dispute, access, security, platform, license, or transfer conditions remain unresolved.
12.2 Account Standing condition. Customer must reach Account Standing before transfer eligibility unless Sites approves a written settlement-transfer exception.
12.3 Transfer hold record. Transfer withholding must be recorded with payment status, default status, dispute or chargeback status, term status, platform status, access status, customer communications, and restoration or transfer conditions.
12.4 Transfer hold neutrality. Transfer withholding does not decide copyright ownership, assignment status, work-made-for-hire status, implied-license scope, tax treatment, accounting treatment, write-off treatment, refund or credit treatment, or collection rights. Ownership-transfer consequences remain governed by the Ownership Transfer Terms.
13. Termination, Settlement, Write-Off, And Collections Review
13.1 Termination review. Termination is not the first default step. It requires Final Default Review unless an urgent security, fraud, excluded-use, unlawful, or platform-risk event requires faster restriction.
13.2 Settlement. Settlement must be recorded with amount, payment timing, credit or write-off treatment, account-standing result, service status, transfer impact, release or closure conditions, and approval owner.
13.3 Write-off. Write-off must be recorded with accounting category, customer status, service status, transfer impact, and reason.
13.4 Collections review. Collection referral is not a standard default remedy. It may occur only if separately approved after review of the specific facts, documents, jurisdiction, amount, records, and customer communications.
13.5 Attorney fees and costs. Attorney-fee recovery, collection costs, late fees, interest, acceleration, remaining-term recovery, liquidated damages, or similar remedies must not be treated as approved by these Terms unless separately stated in a signed customer-visible document or resolution record.
13.6 Write-off and collection separation. A write-off record is an accounting or customer account event and does not by itself waive rights, approve collections, establish tax treatment, or create Account Standing unless the approved resolution record says so. Collection referral requires separate approval and must not be triggered automatically by accounting write-off.
13.7 Settlement and tax/accounting neutrality. Settlement, service credit, refund, write-off, chargeback outcome, restoration, and termination review do not by themselves decide tax income timing, book treatment, write-off treatment, refund or credit accounting, sales-tax treatment, or customer account treatment.
13.8 Settlement authority record. Any settlement or default-resolution amount must identify the original invoice or payment item, amount forgiven or adjusted, new amount due, payment timing, service or transfer effect, release or non-waiver language status, tax and accounting status, approver, and customer-visible record before it is charged, collected, credited, written off, or used to decide Account Standing.
13.9 Write-off does not decide customer status. Accounting write-off, invoice uncollectible status, voiding, chargeback loss, or accounting cleanup does not by itself waive rights, prove tax treatment, approve collections, create Account Standing, approve transfer eligibility, or close the customer dispute. A separate Default Resolution Record must state the customer-visible result, collection status, transfer status, tax and accounting status, and approval owner.
14. Rejected Default Remedies
These Terms reject the following as standard default remedies unless a signed amendment or other approved written record expressly provides otherwise:
acceleration;
liquidated damages;
automatic collection of remaining-term amounts;
immediate termination without Notice and Cure Period except urgent security, fraud, excluded-use, unlawful, or platform-risk events;
aggressive collections as a standard workflow;
automatic ownership transfer after default;
customer portal cancellation that bypasses payment, term, default, or transfer conditions;
hidden or surprise default charges not supported by the signed documents and customer-visible payment or default records;
automated collections or automated aggressive remedy escalation without manual review;
suspension that blocks customer access to required payment or default notices, security or privacy communications, or legally sensitive communications without an urgent-risk record.
15. Default Records
Sites may maintain default-related records for:
failed-payment events;
retry schedule;
invoice and payment records;
notice and Cure Period records;
customer response;
Service Pause or Suspension status;
chargeback or dispute status;
refund, credit, settlement, or write-off records;
termination or restoration review;
ownership-transfer hold;
customer-delay linkage;
affected service period or milestone;
disputed and undisputed amounts if a good-faith dispute exists;
tax or accounting review where applicable; and
transfer-hold evidence.
security, privacy, and offboarding status if service restriction affects access, integrations, credentials, data, or accounts;
final default resolution.