DEV Community: Memo

The “Who Logs In?” Audit: Untangling Super-Admin Rights vs. Billing Contact Rights on Client Software

Memo — Wed, 04 Nov 2026 02:08:59 +0000

Picture a composite scenario. It is 2:15 PM on a Tuesday, and your agency gets an urgent call from a high-value client. Their customer portal or e-commerce stack has started throwing authentication errors, and operations have stalled.

Your senior developer finds the cause within minutes. A third-party subscription the site depends on lapsed after a failed card renewal. They open the vendor’s console to update the card or retry the charge and hit a wall: “Insufficient Permissions.”

The vendor’s warning emails over the previous weeks went to a former marketing coordinator who left eight months ago. Nobody on the client’s current team saw them. Your developer has technical access but no billing access. The client’s executives are asking why the site is down, and your agency is the one answering.

This is not a code defect. It is an account governance failure. Agencies routinely fall into the gap between Super-Admin rights (who can configure the system) and Billing Contact rights (who can pay for it, and who gets told when payment fails). A short, repeatable “Who Logs In?” audit closes that gap before it becomes an outage.

1. Why Super-Admin and Billing Rights Get Confused

Most serious platforms separate technical administration from financial administration, and the split is deliberate. The trouble is that the separation is rarely visible during signup, so clients and agencies each assume the other side has the access.

        +---------------------------------------------+
        |        ACCOUNT OWNER / PRIMARY CONTACT      |
        |  (client-controlled; root or owner identity)|
        +----------------------+----------------------+
                               |
            +------------------+------------------+
            |                                     |
            v                                     v
+-------------------------+         +---------------------------+
|  TECHNICAL ADMIN ROLES  |         |  BILLING / FINANCE ROLES  |
|  (agency engineers,     |         |  (client finance or ops)  |
|   delegated access)     |         |                           |
+-------------------------+         +---------------------------+
| - API keys, webhooks    |         | - Payment methods         |
| - Deployments, config   |         | - Invoices, receipts      |
| - User and team access  |         | - Plan and tier changes   |
| - Integrations          |         | - Billing notifications   |
+-------------------------+         +---------------------------+
            |                                     |
            +------------------+------------------+
                               v
              +-------------------------------+
              |      THE GOVERNANCE GAP       |
              | Alerts reach people who can't |
              | act; people who can act never |
              | see the alerts.               |
              +-------------------------------+

How major platforms actually draw the line

The details differ by vendor, which is why a per-tool audit beats a general assumption.

AWS: By default, IAM users and roles can’t access the Billing and Cost Management console, even if their IAM policies grant billing permissions. The root user has to turn on “Activate IAM Access” first. An agency engineer with full administrator permissions can therefore be locked out of invoices and payment settings.
Google Cloud: The Billing Account Administrator role manages payment methods, exports, and project links. Google’s own documentation notes that Project Owner and other resource-level admin roles don’t grant the permissions needed to see basic billing account information. Only Billing Account Administrators can contact Cloud Billing Support, and the person who creates the billing account is an administrator by default.
Stripe: The Super Administrator role goes to the creator of a business account. There can be only one Account Owner per account, and only the owner can transfer ownership.
Shopify: Changing the plan requires the store owner or a staff member with the “Manage plan” permission. Bills are emailed to the store owner and to any staff with the “View billing and receive billing emails” permission.

The common thread is that the person who signed up usually becomes the owner with the broadest rights. Every later handoff, from that person to the agency or to a new employee, is where billing visibility is lost.

The two classic onboarding mistakes

The “Hand Over the Keys” mistake. The client gives the agency the original owner’s login. When that employee leaves and IT deactivates their mailbox, the account’s recovery email, MFA prompts, and billing notices can disappear with it.
The “Developer as Vendor” mistake. The agency creates the account under a developer’s work email and enters the client’s card. When that developer leaves the agency, the client doesn’t hold the identity that owns their own infrastructure.

2. How the Blame Lands on the Agency

These are composite, illustrative scenarios, not reports of specific incidents. Each reflects a documented permission model.

Scenario A: The ghost inbox

A client’s former operations manager signed up for a third-party service with her individual work email. After she leaves, IT removes the mailbox. The client replaces its corporate card, the next renewal fails, and every payment-failure notice goes to an address nobody reads.

How severe the outcome is depends on the vendor. Some providers suspend features, some downgrade the plan, and some stop service entirely. A real example of the severe end is Google Cloud. If a Cloud Billing account is suspended, all resources attached to it are suspended as well, and if it stays invalid for a protracted period some resources might be removed and are not recoverable. Google’s own restart guidance adds that when a billing account is closed, all billable services in all linked projects are stopped, and some resources might be deleted and not fully recoverable. Many customers resolve a suspension without losing anything, but the guidance is why a lapsed billing contact matters.

The site breaks, the client sees “broken,” and they call the agency.

Scenario B: The administrator who can’t see the bill

Your engineers have administrator access to the client’s AWS account. A usage spike or an expiring payment method needs attention, and nobody on your side can open the billing console, because the root user never activated IAM access to billing. In Google Cloud, the equivalent is an engineer who is a Project Owner but holds no billing role. The engineer can fix the code but can’t see an invoice, change a payment method, or reach billing support.

Without a named financial escalation contact, the fix waits for someone on the client side who is out of reach. The agency still gets the blame for the outage.

3. Step-by-Step: Running the “Who Logs In?” Audit

Make account governance a standard, billable part of onboarding and maintenance. The audit has four stages.

        THE 4-STAGE GOVERNANCE AUDIT
 +---------------------------------------------+
 | 1. INVENTORY & MAP                          |
 |    Every SaaS, API, domain, and service     |
 +----------------------+----------------------+
                        v
 +---------------------------------------------+
 | 2. AUDIT ROLES & CONTACTS                   |
 |    Owner vs. technical admin vs. billing    |
 +----------------------+----------------------+
                        v
 +---------------------------------------------+
 | 3. DECOUPLE & DELEGATE                      |
 |    Role-based inboxes, vaults, delegation   |
 +----------------------+----------------------+
                        v
 +---------------------------------------------+
 | 4. DOCUMENT & FORMALIZE                     |
 |    Access matrix + contract language        |
 +---------------------------------------------+

Stage 1: Map the software inventory

List every third-party service the project depends on, including small ones like transactional email, search, and form tools. For each, record who owns the account, who receives billing notices, and who holds technical access.

The table below is an illustrative example with placeholder addresses.

Service	Function	Account Owner	Billing Contact	Technical Admin
Cloud hosting	Infrastructure	`owner@client.com`	`ap@client.com`	`dev-team@agency.com`
Payment gateway	Payments	`cfo@client.com`	`ap@client.com`	`dev-team@agency.com`
Email delivery	Transactional mail	`ex-employee@client.com` (RISK)	`ex-employee@client.com` (RISK)	`dev-team@agency.com`
Site search	Search	`dev@agency.com` (RISK)	`dev@agency.com` (RISK)	`dev-team@agency.com`

Flag any row where the owner or billing contact is a departed person or an agency employee.

Stage 2: Audit roles and permitted actions

For each service, answer four questions:

Who receives payment notifications and invoices? It should be a monitored role-based inbox, not an individual’s address. On AWS, check the alternate contacts for billing, operations, and security. AWS’s own baseline guidance recommends email distribution lists for these contacts and notes that you must retain access to them.
Who holds the owner or root identity? It should be a current employee of the client, tied to a client-controlled domain.
Can the agency do its technical work without holding payment liability? Delegated roles should cover this.
What is the MFA recovery path, and does it depend on one person’s phone? Check this before the person leaves, not after.

On that last point, the standards have moved. AWS ended support for enabling SMS-based MFA. It now enforces MFA for root users on all account types, and it lets root and IAM users register up to eight MFA devices, so a lost phone doesn’t have to mean a lockout. NIST’s SP 800-63B-4 classifies SMS and other PSTN-based out-of-band authentication as a restricted authenticator. It remains permitted, but the implementing organization must assess and accept the risk. An owner account whose only second factor is a departed employee’s SMS number is a governance failure waiting to happen.

Stage 3: Decouple and delegate

Keep financial identity with the client and technical delegation with the agency.

Rule 1: The client owns the subscription. The client should hold and pay for its own software accounts. Agency-held accounts billed to an agency card and passed through on invoices can create billing friction and ownership disputes when the relationship ends.
Rule 2: Use role-based addresses. Use shared aliases such as saas-billing@clientcompany.com for billing, and dev-alerts@agency.com on the agency side for technical alerts. Individual mailboxes should not be the contact of record for billing or recovery.
Rule 3: Delegate access, don’t share logins. Use each platform’s built-in delegation instead of passing around the owner’s password. Examples:
- Microsoft 365 partners: Granular delegated admin privileges (GDAP) give partners specific, time-bound access, in place of the older DAP model that granted broad standing access. GDAP relationships have a defined end date, with a maximum of two years, so put the expiry on your calendar.
- Shopify: Give agency staff only the permissions they need and leave the billing and payment permissions with the client.
- AWS: Prefer identity federation with IAM Identity Center over shared credentials. AWS recommends this as a security best practice.
- Google Cloud: Grant the narrow billing roles that fit the task. The Project Billing Manager role, for example, can link a project to a billing account without granting any rights over resources.
Rule 4: Use a password manager for what can’t be delegated. Where a service offers no delegated roles, store shared credentials in an encrypted vault such as 1Password, Bitwarden, or Keeper, never in chat or email. Rotate secrets whenever someone with access leaves.

Stage 4: Document and formalize

Publish the access matrix from Stage 1 to both sides and attach it to the contract. Every row should name an owner, a billing contact, a technical contact, and a backup. Review it on a schedule.

4. Contractual and Operational Protection

An audit tells you where the gaps are. The contract decides who pays when one of them breaks something.

Put ownership and payment responsibility in the agreement

Add language to your Master Services Agreement or Statement of Work that states where responsibility sits. A sample you can adapt:

Third-Party Services and Account Ownership. Client retains ownership of, and responsibility for payment of, all third-party software, APIs, hosting, and SaaS subscriptions required to operate the application, and shall maintain current, monitored billing and security contacts for each. Agency is not responsible for service interruptions resulting from lapsed payment methods, unmonitored billing contacts, or access changes made by Client or the third-party provider.

Have a qualified attorney review any limitation-of-liability language. Enforceability varies by jurisdiction, and this sample is not legal advice.

Define an emergency escalation protocol

When a payment fails and a tool goes down, speed matters. Agree on the following in writing before an incident:

A named financial escalation contact on the client side, with the authority and the platform role to approve payments. On Google Cloud, for example, that means someone who holds the Billing Account Administrator role, since only those administrators can contact Cloud Billing Support.
Pre-authorized limits. State whether the agency may temporarily cover an unpaid third-party bill up to a set amount (for example, $250) to prevent an outage, with reimbursement guaranteed by the client.
A response clock. Specify how quickly the client contact must respond, and who stands in when they’re out of reach.

5. Checklist: The “Who Logs In?” Framework for Onboarding

Use this when onboarding a client or launching a major project:

Ownership verified: Every account is registered under a client-controlled domain, not an agency address or a contractor’s personal email.
Billing routing confirmed: Invoices, failed-payment alerts, and card-expiry warnings go to a monitored role-based alias.
Billing access mapped: Someone with real billing permissions is named for each service, using that platform’s own roles (for example, an AWS root user who has activated IAM billing access, or a Google Cloud Billing Account Administrator).
Technical access delegated: Agency developers use individual, delegated credentials with technical permissions only, not shared owner logins.
MFA recovery verified: Owner accounts have more than one registered MFA method where the platform allows it, preferably passkeys or security keys. No account depends on one person’s SMS number.
Backup owner assigned: At least two active client stakeholders can administer each critical account. Where a platform allows only one owner, as Stripe does, a second Super Administrator fills the gap.
Delegation expiries tracked: Time-limited relationships, such as Microsoft GDAP, have renewal dates on the calendar.
Review scheduled: Access lists, billing contacts, and departed-user clean-up are reviewed every 90 days.

Conclusion: Turning Governance into a Value-Add

Billing contacts that nobody reads and permissions that don’t match responsibilities are a silent risk to any production site. Vendors such as AWS, Google Cloud, Stripe, and Shopify already offer the separation of duties you need. What they can’t do is make sure the right person holds each role when something fails.

Running a “Who Logs In?” audit at onboarding, and again every quarter, protects your team from blame it didn’t earn and gives clients a clear picture of who owns what. It also positions your agency as the partner that treated account access as part of the engagement.

Originally published at https://instarenewal.com/blog/the-who-logs-in-audit-untangling-super-admin-rights-vs-billing-contact-rights

The “I Didn’t Authorize That” Dispute: How to Pre-Clear Renewal Invoices Without Killing Momentum

Memo — Tue, 03 Nov 2026 02:02:48 +0000

Every agency leader, SaaS provider, and retainer-based business knows the sinking feeling of a notification like “Dispute opened: Reason: Fraudulent.” For ACH debits, the equivalent is a return coded as unauthorized.

The scenario is painfully predictable:

An annual or quarterly contract renews automatically.
Your payment processor charges the card or bank account on file.
The client’s finance team, or a busy executive who forgot the renewal date, spots the charge.
Instead of contacting account management, they call their bank and say, “I didn’t authorize this.”

What should have been a contract extension becomes an operational problem. The disputed amount is pulled from your balance, you pay a fee whether you win or lose, and the dispute counts toward the ratios your processor and the card networks monitor. Even if you win by pointing to a clause in a contract signed a year ago, the account is strained.

This guide covers what a renewal dispute costs, why clients file them, how to build pre-authorization into onboarding, and what to do when one arrives. It reflects card network and regulatory rules as of November 2026.

Note: This article is general information, not legal advice. Have counsel review your contract language, your renewal notices, and your state-law exposure.

1. The Real Cost of Renewal Friction

A chargeback costs more than the invoice itself.

[ Automated charge hits card ]
              │
              ▼
[ Client files "unauthorized" dispute ]
              │
      ┌───────┴────────────────┐
      ▼                        ▼
[ Cash impact ]         [ Monitoring impact ]
• Disputed amount       • Dispute fee, win or lose
  pulled from balance   • Counts toward network and
• Work continues          processor dispute ratios
  unpaid, or stops
      │                        │
      └───────┬────────────────┘
              ▼
[ Relationship strain ]
• Lost trust, escalations, paused work

What it costs

Fees you can’t recover. On Stripe in the US, every dispute carries a $15 fee that is not returned even if you win. Since June 17, 2025, Stripe also charges a $15 counter fee when you submit evidence, which is refunded if you win. A lost, contested dispute therefore costs $30 plus the disputed amount. Other processors set their own fees, so check your pricing page.
Disputes stay on your record even when you win. Stripe’s documentation states that all disputes count toward your dispute rate, won or lost.
Visa’s VAMP ratio. Visa’s Acquirer Monitoring Program (VAMP) combines fraud reports and disputes into one ratio, calculated as (TC40 fraud reports + TC15 disputes) ÷ settled card-not-present transactions. Since April 1, 2026, merchants in the US, Canada, the EU, Asia Pacific, and Latin America are flagged as “Excessive” at a ratio of 1.5% (down from 2.2%), provided they have at least 1,500 combined fraud reports and disputes in a month. Excessive merchants are charged $8 per disputed or fraud-reported transaction. Acquirers face a much tighter bar of 0.5% (Above Standard) and 0.7% (Excessive).
Mastercard’s program. Mastercard’s Excessive Chargeback Merchant (ECM) tier applies at 100 or more chargebacks in a month and a ratio of 1.5% or higher.
Your processor’s own limits. A small agency will rarely hit a network volume floor like 1,500 disputes a month. But processors and acquirers apply their own risk rules, and acquirers push pressure down to merchants. A handful of disputes on a small account can still draw scrutiny, including reserves, tighter terms, or account review.
Awkward account management. Continuing work while the client contests payment creates unrecoverable cost. Pausing work risks breaching SLAs and the remaining goodwill.

2. Why Clients File “Unauthorized” Disputes (It’s Not Always Malice)

To prevent disputes, understand why client contacts go to their bank instead of your support team.

The desk-swap effect. The executive who signed the agreement may have moved on. A new accounts payable contact doesn’t recognize your company name on the statement and treats the charge as fraud.
The shock invoice. A renewal for several thousand dollars with no prior notice triggers alarm in any accounting department.
Descriptor mismatch. If your legal entity is “Acme Holdings LLC” but the client knows you as “Launch Digital,” a charge under the legal name is a common trigger for “I don’t recognize this” claims.
The bank as a cancellation shortcut. A client who missed the opt-out window, or found cancellation confusing, may use a dispute to stop the charge. This is typically filed as a cancelled recurring claim (Visa reason code 13.2) rather than a fraud claim, and the evidence you need differs.

For card payments, “I didn’t authorize this” is usually filed as card-absent fraud (Visa reason code 10.4). For ACH, it arrives as a return code, covered in Section 6.

3. Designing Pre-Clearance Checkpoints in Onboarding Documents

The strongest prevention is unambiguous agreement during onboarding, long before the first renewal.

Essential clauses for your Master Services Agreement

A. Express recurring billing authorization

Put the payment authorization in its own clearly marked clause, not buried in general terms.

Model clause: Billing & Payment Authorization

“Client authorizes [Company Name] to store payment credentials (credit card or ACH details) through its PCI-compliant payment provider and to charge the payment method on file for recurring subscription or retainer fees on each renewal date. Billing will continue at the agreed cadence until Client provides written notice of non-renewal under Section [X].”

For ACH debits, authorization language must also meet the rules of your bank and Nacha, so have your processor or counsel review it.

B. Clear non-renewal window rules

State exactly how and when a client can stop a renewal, and make sure your reminder arrives before that deadline. A 30-day reminder is useless if the contract required notice 60 days ahead.

Day 0      Day 275          Day 305        Day 335         Day 358       Day 365
  │           │                │              │               │             │
Contract   First renewal    Opt-out        Invoice preview  Final         Renewal
signed     reminder         deadline       and payment      reminder      charge
           (90 days out)    (60-day        method check     (7 days out)
                            notice)        (30 days out)

Notice period: Define whether non-renewal requires 30, 60, or 90 days’ written notice.
Delivery channel: Name the exact email address or portal for notices (for example, billing@yourcompany.com).

C. A billing-question escalation path

Give clients a fast, documented way to raise a billing question before going to their bank.

Model clause: Billing Inquiries

“Before disputing a charge with its bank or card issuer, Client agrees to notify [Company Name] at billing@yourcompany.com so the parties can resolve the question. [Company Name] will respond to written billing inquiries within five (5) business days and will correct verified billing errors.”

A contract cannot take away a cardholder’s right to dispute a charge through their bank, and a clause like this will not bar it. Treat it as a courtesy path that sets expectations and shows good faith, not as a restriction. Avoid wording that penalizes a client for filing a dispute, and have counsel review it.

4. The Renewal Pre-Clearance Workflow

Legal terms alone won’t stop a surprised client from calling their bank. Build a communication sequence around every renewal.

Stage 1: The renewal notice (30 or more days out)

Send a clear notice to both the primary contact and the accounts payable contact. Timing matters for compliance as well as for the client:

Mastercard requires notice 7 to 30 days before billing for recurring charges six months or more apart.
Visa and Mastercard require a reminder at least 7 days before the first charge after a trial or a change in billing terms. Neither network’s rules are written around B2B retainers, so confirm what applies with your acquirer.
California requires consumer businesses with initial terms of one year or longer to give renewal notice 15 to 45 days before renewal.

A reminder around day -30, plus a second short reminder 7 to 14 days out, satisfies all of these timing windows and gives the client two chances to react.

Pre-renewal notification email template

Subject: Upcoming renewal: [Company Name] services starting [Date]

Hi [Client Name],

Thank you for your partnership this past year. Your service agreement for
[Product/Service Name] renews soon. Here are the details:

• Service period: [Start Date] to [End Date]
• Renewal amount: $[Amount]
• Payment method on file: [Card Brand / Bank Name] ending in [1234]
• Scheduled billing date: [Exact Date]
• Charge will appear on your statement as: [Descriptor]

What you can do:
1. Review your renewal invoice: [Link]
2. Update your card, bank details, or accounts payable contact: [Billing Portal Link]
3. Change your plan or cancel before [Opt-Out Cutoff Date]: reply to this email
   or contact [Account Manager] at [Email]. Cancellation instructions are
   in Section [X] of your agreement.

Best regards,
[Name / Billing Team]

Stage 2: Account management alignment (14 or more days out)

For high-value contracts, pair automated emails with a human touchpoint:

Share results. Send a performance or ROI summary before the invoice lands.
Verify accounts payable requirements. Ask whether the invoice needs a purchase order number or internal approval. Missing PO numbers are a common reason finance teams reject or dispute charges.

Stage 3: Charge day, with a recognizable descriptor

The statement descriptor is the line your client’s finance team actually sees, and it has hard limits. On Stripe, a descriptor must be 5 to 22 characters, contain at least one letter, and cannot include the characters <, >, ', ", or *. Longer strings get truncated unpredictably.

Risky: ACME HOLDINGS LLC (a legal entity name clients don’t recognize)
Better: LAUNCH DIGITAL or LAUNCHDIGITAL RENEWAL

Send a receipt immediately after the charge that repeats the amount, service period, and how to manage or cancel the subscription.

5. Regulatory and Network Rules: What Applies to B2B

Most auto-renewal law is written to protect consumers. Whether it reaches your business-to-business contracts depends on who your customer is and where they are. Don’t assume it applies, and don’t assume it doesn’t.

FTC rules. The Restore Online Shoppers’ Confidence Act (ROSCA) remains in force. It governs online sales with negative-option features and requires clear disclosure, express informed consent, and a simple cancellation mechanism. The FTC’s broader “Click-to-Cancel” rule was vacated in its entirety by the Eighth Circuit on July 8, 2025. The FTC issued an advance notice of proposed rulemaking in March 2026 to begin building a new version, so the rules may change.
State auto-renewal laws. More than half of US states have automatic-renewal laws. California’s law applies to consumer subscriptions and was strengthened effective July 1, 2025. It now requires an annual reminder, 15 to 45 days’ notice before renewal for terms of a year or longer, and 7 to 30 days’ notice of fee changes. If you sell to sole proprietors or very small businesses, ask counsel whether these laws could reach them.
Card network rules. Visa and Mastercard rules focus on trial conversions, changes in billing terms, and infrequent recurring charges, as covered in Section 4. Network compliance does not replace federal or state compliance.
ACH. Nacha monitors unauthorized return rates, with a threshold of 0.5% across return codes R05, R07, R10, R11, R29, and R51.

Even where no law requires it, the practices these rules describe (clear consent, advance notice, easy cancellation, recorded proof) are what win disputes.

6. Card Disputes vs. ACH Returns

If you collect by ACH, the “unauthorized” timeline looks different:

Account type	Return code	Window to return
Consumer account	R10 (customer advises not authorized)	Up to 60 calendar days
Business account (CCD/CTX debits)	R29 (corporate customer advises not authorized)	2 banking days

Business-account debits get a much shorter window, so a late-surfacing dispute is more likely on a card than on a corporate ACH debit. Unauthorized ACH returns generally must not be retried without a new authorization. Card disputes follow the network timelines in the next section.

7. Structuring Onboarding to Secure Pre-Authorization

Step 1: MSA sign-off      Step 2: Payment portal     Step 3: Kickoff call
┌──────────────────┐      ┌──────────────────┐       ┌──────────────────┐
│ Separate consent │ ───► │ Tokenized card   │ ────► │ Confirm renewal  │
│ checkbox for     │      │ or bank capture  │       │ dates, notice    │
│ recurring billing│      │ via PCI gateway  │       │ rules, AP contact│
└──────────────────┘      └──────────────────┘       └──────────────────┘

1. A dedicated billing consent checkbox

Don’t bury auto-billing terms in a 20-page agreement. At signing or checkout, add a separate consent line:

[ ] I authorize [Company] to charge my card or bank account on a recurring basis
    for contract renewals until canceled under the termination terms of the agreement.

Record the timestamp, IP address, and the exact wording shown. This is your best evidence later.

2. Tokenized payment capture and card updates

Capture payment details through a PCI-compliant gateway such as Stripe, Adyen, or Braintree. Tokenization keeps raw card data off your systems, but it does not by itself refresh expired cards. For that, enable your processor’s card account updater service, which pulls new card details from participating issuers and reduces failed renewals.

3. The kickoff call

Spend two minutes on billing logistics:

Confirm who receives renewal invoices.
Ask whether their accounting setup needs PO numbers, vendor portal registration, or tax exemption certificates.
Record these preferences in your CRM (HubSpot, Salesforce, or equivalent).

8. What to Do When a Dispute Arrives

Even with a strong process, some disputes will happen.

Step 1: Reach out directly (within 24 hours)

Call or email your primary contact. Often the executive doesn’t know finance filed a dispute. If it was a mistake, they can ask their bank to withdraw it. Check your processor’s guidance before refunding a charge that is already disputed, because you can end up paying twice.

Re-engagement email template

Subject: Question about your recent renewal charge ([Invoice #])

Hi [Client Executive Name],

Our payment processor notified us that a dispute was opened for your renewal
invoice ([Invoice #], $[Amount], processed [Date]).

This payment covers [Start Date] through [End Date] under our agreement
signed [Date]. If your finance team flagged it because of an accounting
update or a missing PO number, we're happy to correct the details or
work out a solution quickly.

Could we have a quick call today to sort this out?

Best regards,
[Name]

Step 2: Respond with evidence before the deadline

Response windows are set by the card networks and typically run 7 to 21 days, and a missed deadline is an automatic loss. Check the due date in your processor dashboard first. Evidence that supports an “unauthorized” defense:

Proof of consent. The signed contract or checkout audit log with IP address, timestamp, and the recurring billing authorization.
Proof of notification. Delivery logs for your renewal notices and receipts.
Proof of use. Platform logs, deliverables, approvals, and email exchanges showing the client used the service during the billed period.
Payment history. Prior successful charges that were not disputed.

A note on Visa’s Compelling Evidence 3.0 (CE 3.0). For Visa 10.4 disputes, CE 3.0 lets you show two prior undisputed transactions on the same card, processed 120 to 365 days before the disputed charge, with matching data such as IP address or device. Stripe notes its validator uses 120 to 364 days. This helps with monthly and quarterly billing, but a client’s first annual renewal generally can’t qualify, because only one earlier charge exists. Annual contracts therefore depend even more on your consent record and renewal notices.

Also remember that winning a dispute recovers the money but does not remove it from your dispute rate. Prevention beats representment.

Summary Checklist: Building a Frictionless Renewal Engine

Contract clarity

Separate recurring billing authorization clause in the MSA
Unambiguous non-renewal window, with a reminder sent before the deadline
Separate consent checkbox with recorded timestamp and IP

Proactive notification

Renewal notice about 30 days out, plus a second reminder 7 to 14 days out
Notices go to both the primary contact and accounts payable
Account manager check-in on high-value accounts

Billing transparency

Statement descriptor that matches client-facing branding (22 characters or fewer on Stripe)
Card account updater enabled
PO numbers and invoicing requirements collected in advance

Dispute readiness

24-hour outreach process for any dispute
Retained logs: consent, IP, timestamps, email delivery receipts, usage records
Response deadline tracking and a clear escalation path between finance and account management

Pairing clear consent with proactive, well-timed renewal communication removes most billing surprises. That protects your processing standing, your recurring revenue, and the relationships behind it.

Sources and Further Reading

Visa VAMP thresholds: Fraudio, Dodo Payments, Chargeflow
Stripe dispute fees: Stripe support, Redo
Stripe statement descriptor rules: Stripe docs
Visa Compelling Evidence 3.0: Stripe support, Checkout.com
FTC Click-to-Cancel and ROSCA: Cooley, BCLP
California Automatic Renewal Law: California Attorney General
Visa and Mastercard recurring billing rules: Finix, Chargeback Gurus
ACH return codes and unauthorized return rates: EPCOR, Dwolla

Originally published at https://instarenewal.com/blog/the-i-didn-t-authorize-that-dispute-how-to-pre-clear-renewal-invoices-without

The “Who Holds the Keys?” Audit: Mapping Registrar Account Ownership vs. Agency Operational Access

Memo — Mon, 02 Nov 2026 02:14:08 +0000

In digital marketing, web design, and managed IT services, few situations turn ugly as fast as a client-agency offboarding that goes wrong.

A client decides to move to a new provider or bring their marketing in-house. They ask for access to their website, DNS records, and domain portfolio. The agency replies with an invoice for “transition fees.” Or it points out that the domain sits inside the agency’s master GoDaddy, Namecheap, or Cloudflare account, so the client has no account to log in to. A routine vendor transition becomes a dispute over digital custody.

The root cause is usually confusion between technical administrative access and registrar account ownership. Being able to edit DNS records does not make an agency the owner of a domain. And paying a monthly retainer does not mean the client controls the account where the domain actually lives.

This audit framework explains how the two differ, how to check where your domains actually sit, and how to structure agency-client access so nobody can be held hostage.

Technical Admin Rights vs. Account Ownership

Domain governance mixes two layers that are easy to blur: who is named as the registrant and who controls the registrar account.

A domain registration is not a deed to physical property. It is a registration held through an ICANN-accredited registrar, recorded at the registry (Verisign operates .com), and governed by the registrar’s terms and ICANN policy. Whether that registration counts as “property” depends on the jurisdiction. The U.S. Ninth Circuit held in Kremen v. Cohen (2003) that a registrant has an intangible property right in a domain name, at least under California law. Other jurisdictions treat the question differently. Either way, practical control usually comes down to who can log in to the account the domain sits in.

+-----------------------------------------------------------------------------------+
|                           REGISTRAR ACCOUNT (OWNER)                               |
|  - Controls account-level login, MFA, recovery email, and payment methods.        |
|  - Can unlock the domain and obtain the Transfer Authorization Code (TAC).        |
+-----------------------------------------------------------------------------------+
                                         |
               +-------------------------+-------------------------+
               |                                                   |
               v                                                   v
+-------------------------------------+   +-------------------------------------+
|        REGISTRANT (ON RECORD)       |   |        DELEGATED / TECH ACCESS      |
|  - The person or organization       |   |  - Edits DNS records (A/CNAME/MX).  |
|    named as holder of the domain.   |   |  - Scope set by the account owner.  |
|  - The party ICANN policy treats    |   |  - Can be revoked at any time.      |
|    as the Registered Name Holder.   |   |                                     |
+-------------------------------------+   +-------------------------------------+

Contact Roles: What Still Exists

Domains historically listed four contacts: registrant, administrative, technical, and billing. That model is largely gone for generic TLDs such as .com.

The Registrant (Registered Name Holder): The person or organization that holds the registration and is the contract party under ICANN’s policies. Under the ICANN Registration Data Policy, which took effect August 21, 2025, the registrant contact is the only contact universally required for gTLDs.
Administrative, technical, and billing contacts: These are no longer part of the required data set. Many registrars have stopped collecting them for most gTLDs, and some registries still accept them. Where they exist, they are just designated people, such as an employee or a web developer. Being listed there conveys no ownership.
Historical note: ICANN’s older Transfer Policy let either the registrant or the administrative contact (the “Transfer Contact”) authorize transfers. The Transfer Policy Review working group recommended replacing those references with “Registered Name Holder.” The ICANN Board adopted the review’s recommendations on June 7, 2026, and implementation is still to come.

The point of this audit is not to find a technical contact. It is to find out who controls the registrar account and who is listed as registrant. These are often two different parties.

The Core Conflict: Agency Master Account vs. Client-Owned Account

Agency master account (high risk): The agency registers the client’s domain inside its own registrar account (for example, GoDaddy Pro or a Cloudflare account it owns). Even if the client is named as registrant, the agency holds the login, recovery email, and MFA device. To transfer the domain to a new registrar, the client needs a Transfer Authorization Code (TAC). The client can only get one through the account holder, so in practice the client needs the agency’s cooperation.
Client-owned account with delegated access (best practice): The domain sits in a registrar account created under the client’s legal entity and a corporate email address. The agency is invited as a delegate or member with limited permissions, enough to edit DNS records without touching billing, recovery settings, or transfer controls.

Anatomy of a Domain Custody Battle

Most of these disputes do not start with bad intent. They start with onboarding shortcuts that nobody revisits.

┌─────────────────────────────────────────────────────────────────────────┐
│                     CHRONOLOGY OF A CUSTODY FAILURE                     │
├─────────────────────────────────────────────────────────────────────────┤
│  1. ONBOARDING SHORTCUT                                                 │
│     Agency registers the client's domain in its own master account      │
│     to move faster on DNS setup.                                        │
├─────────────────────────────────────────────────────────────────────────┤
│  2. OPERATIONAL BLIND SPOT                                              │
│     Client pays monthly invoices and assumes that covers ownership.     │
│     No asset inventory records where the domain actually lives.         │
├─────────────────────────────────────────────────────────────────────────┤
│  3. RELATIONSHIP BREAKDOWN                                              │
│     Client ends the engagement over performance or pricing.             │
├─────────────────────────────────────────────────────────────────────────┤
│  4. DEADLOCK                                                            │
│     Agency withholds the TAC or account handoff pending disputed fees.  │
│     Client cannot move DNS, email, or the domain itself.                │
└─────────────────────────────────────────────────────────────────────────┘

1. The Convenience Trap During Onboarding

When a non-technical client cannot find their old registrar login, the account manager says, “We’ll register it in our account for now and sort it out later.” Three years later the developer who set it up has left, the client’s marketing lead has changed, and the domain is still in the agency’s portfolio.

2. The Personal Employee Registration

A client employee registers a core brand domain using a personal email address or personal credit card. When that person leaves on bad terms, the business loses the password-reset emails, MFA codes, and renewal notices tied to that account.

3. The Reseller Trap

Many agencies resell domains through their own registrar or reseller accounts and invoice the client for renewals. A line item like “Domain Renewal – $25/yr” feels like proof of ownership, but it is not. If the agency disappears or a dispute arises, the registrar deals with its own account holder, and the client has no direct account relationship to rely on. GoDaddy’s complaint policy, for example, says it will not release customer or account information without the customer’s permission, and it acts on court orders, not on one party’s claim to a domain.

The “Who Holds the Keys?” Audit: Five Steps

Run this audit across your own and your clients’ portfolios.

┌────────────────────────────────────────────────────────────────────────┐
│                        DOMAIN AUDIT FLOWCHART                          │
├────────────────────────────────────────────────────────────────────────┤
│  [Step 1: Registration data] ─> Identify registrar & visible registrant│
│                                    │                                   │
│  [Step 2: Account mapping] ──> Who owns the registrar login?           │
│                                    │                                   │
│  [Step 3: MFA & recovery] ───> Where do resets and codes go?           │
│                                    │                                   │
│  [Step 4: DNS & nameservers] > Who can change where the domain points? │
│                                    │                                   │
│  [Step 5: Contract review] ──> Does the MSA match technical reality?   │
└────────────────────────────────────────────────────────────────────────┘

Step 1: Check Registration Data (RDAP)

WHOIS has been replaced by RDAP for generic TLDs. ICANN removed the requirement for gTLD registrars and most registries to run WHOIS on January 28, 2025, and ICANN’s own lookup tool at lookup.icann.org is RDAP-based.

What to check: The registrar of record, the creation and expiry dates, the EPP status codes (such as clientTransferProhibited), and the nameservers.
Limitation: Registrant name, email, and phone are redacted by default for most gTLD domains, in RDAP as in WHOIS before it. The registrant field may therefore show nothing useful. You cannot rely on a public lookup to prove who the registrant is.
What to do instead: Log in to the registrar account that holds the domain and read the registrant details there. Where you do not have access, ask the account holder to show you.
Red flag: The registrant, where visible or shown in the account, names the agency instead of the client.

Step 2: Map the Registrar Account

Identify where the domain actually lives. It might be AWS Route 53, Cloudflare Registrar, GoDaddy, Namecheap, or Squarespace Domains (which took over Google Domains).

What to check: Who owns the account’s primary login email? Is it a role-based client address or a person?
Red flag: The account email is an agency address (ops@agency.com) or an ex-employee’s personal inbox.

Step 3: Audit MFA and Recovery Channels

What to check: Where do password resets, SMS codes, and authenticator prompts go?
Red flag: MFA is tied to one person’s personal phone, which makes that person a single point of failure.

Step 4: Audit Nameserver and DNS Control

Registration and DNS hosting are separate. The registrar holds the registration, while a DNS provider (often Cloudflare, Route 53, or the registrar itself) answers queries for the domain.

What to check: Which nameservers does the domain use, and who administers that DNS account?
Risk assessment: DNS control is powerful. Whoever can edit DNS can redirect the website, change MX records to reroute email, and add TXT records that can satisfy domain-validation checks. DNS access alone does not let someone transfer the domain, but it does let them take the site and the email offline or redirect them. Treat DNS access as sensitive even when the registrar account is safe.

Step 5: Review Contract Alignment

What to check: Does the Master Services Agreement (MSA) state that domain names, DNS zone files, and related accounts belong to the client? Does it require the agency to cooperate with a transfer, and for how long?
Red flag: The contract is silent, or it says the agency “manages” assets without saying who owns them.

Access Matrix: Who Can Do What

This matrix shows typical outcomes when the client owns the registrar account and delegates limited access. Exact permissions vary by provider and configuration.

Action / Capability	Account Owner (Client)	Delegated Agency Access (typical)	Billing-Only User	DNS-Only Role
Obtain the Transfer Authorization Code (TAC)	Yes	Only if transfer permission is granted	No	No
Change account login, recovery email, MFA	Yes	No	No	No
Add or change payment methods	Yes	No	Varies	No
Edit A, CNAME, MX, TXT records	Yes	Yes	No	Yes
Change nameservers	Yes	Depends on permission level	No	Usually no
Renew or buy products	Yes	Depends on permission level	Varies	No

Some platforms let you grant domain transfer permission to a delegate. GoDaddy, for example, lets you give delegates domain management actions, transfer actions, or both. Leave transfer permission off for an agency unless you intend to grant it.

Best Practices: Agency Access Without Sacrificing Ownership

Agencies need real technical access to do their jobs. Clients need legal and practical control over their core assets. Both are possible.

1. Put the Domain in a Client-Owned Account

Rule: Register or transfer domains into a registrar account owned by the client’s legal entity.
Implementation: Create the account with a role-based mailbox, such as domains@clientcompany.com, rather than an individual’s address. Keep at least two people at the client able to recover the account. The client holds the payment method and the root login.

2. Use Native Delegation Tools

Never share the root password. Use the provider’s delegation features instead.

GoDaddy: Use Delegate Access. GoDaddy’s “Products & Domains” level lets a delegate use products and manage domains without making purchases or viewing payment details. For domains, you choose whether delegates can perform management actions, transfer actions, or both. Whatever the level, delegates cannot manage payment methods or invite other people to the account.
Cloudflare: Invite the agency as an account member with a narrow role. Cloudflare’s DNS role can edit DNS records. The Super Administrator role can edit any setting, make purchases, update billing, and manage members, so reserve it for the client’s own staff. Cloudflare recommends keeping more than one Super Administrator so the account does not depend on one person.
AWS Route 53: Use a cross-account IAM role with a custom policy limited to the hosted zone actions the agency needs, such as changing record sets. Do not use the managed policy AmazonRoute53FullAccess for this purpose. AWS documents that it covers domain registration as well as health checks. For domain registration actions, AWS provides the separate AmazonRoute53DomainsFullAccess policy, which an agency should not need for DNS work.

3. Apply Transfer Locks and Consider Registry Lock

Registrar lock: Keep clientTransferProhibited enabled on production domains so a domain cannot be transferred without someone deliberately unlocking it.
Registry Lock: For high-value .com, .net, .cc, and .name domains, Verisign offers Registry Lock through participating registrars. Changes to a locked domain require out-of-band verification between the registrar and Verisign, such as a phone call and a security phrase. Not every registrar offers it, and reporting in the domain industry has noted that GoDaddy does not offer it to customers. Ask your registrar directly before you rely on it.

4. Write Offboarding Into the MSA

Add a standard asset-handoff clause to every agency agreement. A sample, to adapt with your lawyer:

Digital Asset Handoff

Ownership. All domain names, DNS zones, SSL/TLS certificates, and related accounts registered or managed for Client are the property of Client. Where any such asset is held in Agency’s account, Agency holds it on Client’s behalf.

Access revocation. On notice of termination, Client may revoke Agency’s delegated access at any time.

Transfer cooperation. Within five (5) business days of Client’s written request, Agency will provide the Transfer Authorization Code or move the asset into an account Client designates.

No withholding. Agency will not withhold domain registrations, DNS records, or related credentials as leverage in a fee dispute. Fee disputes are resolved separately under this Agreement.

Emergency Remediation: Recovering a Trapped Domain

If a critical domain is stuck in an agency’s or a former employee’s account, work through these steps in order. Be realistic about each one. Registrars generally do not decide ownership disputes, so the fastest route is almost always cooperation, and the slowest is litigation.

Document your claim. Gather payment records, invoices, the contract, incorporation documents, and any historical registration data showing your organization registered or paid for the domain. Note the registrar and the current nameservers.
Send a formal written request. Address it to the agency’s leadership, not just your account manager. Ask for the TAC or a transfer of the domain into your account, and set a reasonable deadline. Refer to the MSA clause if there is one. A short, specific request often works where an angry email does not.
Protect operations while you negotiate. If you control the DNS provider, you may be able to keep the site and email running. If the agency controls DNS, ask for a copy of the full zone file so you can rebuild it elsewhere.
Understand what the registrar will and won’t do. Registrars tend to treat the account holder as their customer. GoDaddy’s published complaint process, for example, says it will comply with a court order about a customer’s domain, and points disputes to the UDRP or the courts. It also says it will not release account information without the customer’s permission. Do not expect a registrar to hand over an account because you can show you paid for it.
Use the right legal tool.
- UDRP: The Uniform Domain-Name Dispute-Resolution Policy lets a trademark owner obtain transfer of a domain only if it proves three things: the domain is identical or confusingly similar to its trademark, the registrant has no rights or legitimate interests, and the domain was registered and is being used in bad faith. It was designed for abusive cybersquatting. Panels have repeatedly dismissed complaints that turn on a contract or business dispute, such as a disagreement over what an agency agreed to hand over. A fee dispute with your own agency is exactly that kind of dispute, so a UDRP complaint may fail even if you hold the trademark.
- URS: The Uniform Rapid Suspension system only suspends a domain. It cannot transfer one. It applies mainly to newer gTLDs, not to .com, .net, or .org.
- Courts: For a contractual or ownership dispute with a vendor, a court claim is usually the appropriate route. Registrars act on court orders. Speak to a lawyer who handles domain and commercial disputes in your jurisdiction.

Executive Audit Checklist

Use this list to review your own or a client’s portfolio.

Ownership

Every domain is listed in a central inventory with its registrar, account owner, and expiry date.
Each domain sits in an account owned by the client’s legal entity.
The registrant named on each domain is the client entity, not the agency or an individual.

Access

The registrar account email is a role-based mailbox, not a personal address.
At least two people at the client can recover the account.
MFA is not tied to one person’s personal phone.
Agency access is through delegation or named members, not a shared password.
Delegated access excludes billing, recovery settings, and (unless intended) transfer permission.

Security

clientTransferProhibited is enabled on production domains.
High-value domains have been assessed for Registry Lock.
DNS administration is held by a known party, and changes are logged where the provider allows it.

Contracts

The MSA states that the client owns domains, DNS, and related accounts.
The MSA requires the agency to cooperate with transfers within a defined number of days.
The MSA says assets cannot be withheld in a fee dispute.

Offboarding

A written offboarding checklist exists and names who revokes which access.
Renewal notices go to a monitored shared mailbox rather than an individual.

Securing Your Digital Footprint

Technical admin rights are an operational necessity for agencies, but they are not a substitute for owning or controlling the registrar account.

Keep account ownership with the client and give the agency delegated operational access. That lets the agency do its job, lets the client leave when it needs to, and keeps a billing or performance dispute from turning into a hostage situation.

Originally published at https://instarenewal.com/blog/the-who-holds-the-keys-audit-mapping-registrar-account-ownership-vs-agency

The “Net-Zero Retainer” Fallacy: Why Bundling Renewal Costs into Fixed-Fee Contracts Destroys Agency Margins

Memo — Sun, 01 Nov 2026 02:05:08 +0000

Across the digital agency landscape, the all-in maintenance care plan is often pitched as a win-win recurring revenue model. Agencies bundle hosting, domain renewals, premium plugin licenses, security tooling, and core updates into one flat monthly or annual fee, for example $300 to $500 per month.

On paper, this gives the agency predictable MRR (monthly recurring revenue) and gives the client one simple invoice. In practice, it hides a financial problem we’ll call the Net-Zero Retainer Fallacy.

When an agency absorbs volatile third-party vendor costs inside a fixed-fee contract, with no adjustment mechanism and no pass-through billing, the retainer’s real margin erodes every renewal cycle. A care plan that launched at a healthy gross margin (say, 70%) can slowly become an administrative burden, or a net loss.

A note on the numbers: Retainer prices, margins, and cost scenarios in this article are illustrative models. Vendor price changes, dates, and policies are cited from public sources and current as of November 1, 2026. Verify them before quoting them to clients.

The Anatomy of the Net-Zero Retainer

The Net-Zero Retainer appears when the growth of bundled third-party hard costs outpaces the price of a fixed agency maintenance agreement.

Most agencies price care plans from a snapshot of vendor costs on the day the contract is signed. The vendors don’t hold still. SaaS pricing is rising far faster than general inflation. Vertice’s SaaS Inflation Index, which tracks real contract pricing, put SaaS price inflation at about 12% year over year in 2025, several times the consumer inflation rate. A flat $3,600 annual retainer (which is $300 a month) leaves the agency holding all of that vendor pricing risk.

Here is the sample cost-squeeze that results. The retainer stays the same while vendor costs climb:

+-----------------------------------------------------------------------+
|              THE AGENCY MARGIN SQUEEZE (ILLUSTRATIVE)                 |
+-----------------------------------------------------------------------+
|  YEAR 1:  [Vendor Hard Costs: $40] -------------> [Margin: $260]      |  $300 Retainer
|  YEAR 2:  [Vendor Hard Costs: $85] -------> [Margin: $215]            |  $300 Retainer
|  YEAR 3:  [Vendor Hard Costs: $170] --> [Margin: $130]                |  $300 Retainer
|  YEAR 4:  [Vendor Hard Costs: $290] -> [Margin: $10]                  |  $300 Retainer
+-----------------------------------------------------------------------+

What Vendors Have Actually Done Recently

The squeeze isn’t hypothetical. Here are recent, documented examples relevant to a typical agency stack:

Vendor / Asset	Change	Effective
`.com` registry (Verisign)	Wholesale fee rises from $10.26 to $10.97 (about 6.9%)	November 1, 2026
`.net` registry (Verisign)	Wholesale fee rises from $10.91 to $12.00 (about 10%)	March 1, 2027
`.io` registry (Identity Digital)	Wholesale fee rises from $50 to $56 (12%)	January 19, 2027
Microsoft 365 Business Basic	$6 to $7 per user per month (about 16.7%)	July 1, 2026
Microsoft 365 Business Standard	$12.50 to $14 per user per month (12%)	July 1, 2026
Twilio SendGrid	Permanent free plan retired; replaced by a 60-day trial	May 27, 2025
WP Rocket	Unlimited-site “Infinite” plan replaced by tiered “Multi” plans with site caps	Rolled out in phases

Sources: Domain Name Wire (.net), Domain Name Wire (.io), Openprovider (.com), The Register (Microsoft 365), Twilio changelog, and PriceTimeline (WP Rocket).

Registry prices are wholesale fees. Registrars set their own retail prices on top, so the amount your clients’ renewals actually go up will vary by registrar.

1. Domain Registry Increases: The Quiet Compounder

Domain pricing is split across several parties. ICANN sets policy and holds the registry contracts. Registry operators such as Verisign (which runs .com and .net) charge registrars a wholesale fee. Registrars then set the retail price. Domains were once treated as a negligible $10–$15 line item, but the wholesale layer now moves on a predictable schedule.

Case Study: The `.com` Price Ladder

Verisign’s .com Registry Agreement allows increases of up to 7% in each of the final four years of every six-year cycle, and Verisign has used that room repeatedly. The wholesale price sat at $7.85 for years, rose to $10.26 by 2024, and goes to $10.97 on November 1, 2026, roughly 40% above the old $7.85 baseline. Verisign must give registrars at least six months’ notice before an increase.

Industry observers expect that further 7% steps could be available in 2027, 2028, and 2029. The compounding math is straightforward:

Cost after n years = Initial cost × (1 + r)^n

Here r is the annual rate of increase and n is the number of years. If Verisign took the full 7% in each of the next three years, the wholesale .com fee would go from $10.97 to roughly $13.44 (10.97 × 1.07³). That is about $3.18 more per domain per year than today’s $10.26.

Across 200 client domains that is roughly $636 a year in wholesale drift, and across 500 domains it is about $1,590 a year, before any registrar markup. A flat retainer absorbs every dollar of it.

Other Extensions Move Too

.net rises about 10%, from $10.91 to $12.00, on March 1, 2027.
.io rises 12%, from $50 to $56, on January 19, 2027. .io is a country-code TLD for the British Indian Ocean Territory, and its long-term future has been debated because of the UK–Mauritius Chagos negotiations. Reporting in April 2026 said the UK had frozen its plans to cede the islands, so .io continues to operate normally.
.info and .pro rise from $21 to $23.50, and .mobi from $40 to $51, on the same January 2027 date.

One practical lever: registries typically bill a registration or renewal at the price in force when the order is placed, and a domain can be renewed for up to ten years in total. Renewing before an announced effective date (before March 1, 2027 for .net, for example) locks in the old wholesale price for those years. That only helps if someone owns the calendar.

2. SaaS and Software License Tier Creep

The biggest source of margin loss in bundled retainers is vendors changing how they package and meter their products. Agencies relied for years on “unlimited site” and agency-wide licenses. Several vendors have narrowed or removed them:

Site caps replacing unlimited tiers. WP Rocket’s unlimited Infinite plan ($299 per year) was replaced by Multi plans with site limits, reportedly 50 sites at the same price at first. Popup Maker also dropped its unlimited-site plan in favor of scaling plans.
Free tiers becoming trials. SendGrid retired its free Email API and Marketing Campaigns plans on May 27, 2025. Sending paused for free accounts after a 60-day transition. New accounts get a 60-day trial of 100 emails per day, and paid plans start at $19.95 per month.
Per-seat repricing. Microsoft’s July 1, 2026 list-price increase pushed Business Basic to $7 and Business Standard to $14 per user per month, while Business Premium stayed at $22. Existing customers generally keep their old price until their next renewal after July 1, so the increase reaches a client tenant at renewal time.
Usage-based scaling. Many providers meter monthly active users, API calls, bandwidth, or storage, and move high-usage customers to higher tiers.

The Client Growth Paradox

Under a bundled retainer, client success reduces agency profitability. Consider this hypothetical e-commerce client whose traffic doubles over 18 months:

Order volume increases usage on the client’s CRM, email automation, and tax-calculation tools.
The host moves the account to a larger plan to handle more concurrent PHP workers.
The transactional email service moves from an entry tier (for example SendGrid’s $19.95 Essentials) to a higher one (SendGrid Pro starts at $89.95).

Say the agency’s hard costs rise from $80 to $380 a month under an all-inclusive $500 care plan. The client pays the same fee, and the agency’s gross margin falls from 84% to 24%: $420 of margin becomes $120. The agency did good work, and the work made the contract worse.

The Operational Risk of Holding Client Assets

Bundling renewals under agency-owned master accounts also creates operational exposure beyond margin.

                       ┌─────────────────────────┐
                       │   Agency Master Account │
                       └────────────┬────────────┘
                                    │
               ┌────────────────────┼────────────────────┐
               ▼                    ▼                    ▼
      ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐
      │ Client A Assets │  │ Client B Assets │  │ Client C Assets │
      └─────────────────┘  └─────────────────┘  └─────────────────┘
                                    │
                         [Failed Credit Card / Churn]
                                    │
                                    ▼
                         ┌────────────────────┐
                         │ Account Suspension │
                         │ Affects ALL Assets │
                         └────────────────────┘

You are the customer of record. If the agency holds the registrar or hosting account, vendors bill and suspend the agency’s account, not the client’s. If a client stops paying the retainer, the agency has to decide whether to keep covering vendor renewals. Your contract governs who is responsible, so check it.
Consolidated payment risk. Dozens of client subscriptions on one master card mean one expired card or fraud block can interrupt many services at once.
Expiry has a clock. If a domain renewal fails, ICANN’s Expired Registration Recovery Policy requires registrars to send expiration notices and gTLD registries to offer a 30-day Redemption Grace Period. During that period DNS resolution is disabled and the domain can be restored, usually with an added fee. Country-code TLDs follow their own rules, and some have no redemption period at all.
Exit friction. When a client leaves, untangling domain ownership, certificates, and license keys from an agency master account is slow and a common source of disputes.

How to Unbundle Renewal Costs Cleanly

To restore margin and reduce liability, shift from absorptive bundling to unbundled pass-through structures.

Step 1: Establish Clear Contract Boundaries

Separate agency labor and expertise from third-party infrastructure and licensing in your agreements.

Sample MSA clause framework (have your own counsel review before use):

“Agency service retainers cover professional labor, management, monitoring, and advisory services only. All third-party software licenses, domain registrations, hosting infrastructure fees, and API utility usage remain the financial responsibility of the Client. Agency may pass through vendor cost adjustments with at least 60 days’ advance written notice, or as much notice as the vendor gave Agency, if shorter.”

Because Verisign gives registrars six months’ notice of .com increases, there is rarely a good reason to give clients less than 60 days.

Step 2: Move Billing to Client-Owned Accounts Where Possible

Wherever vendors support it, have the client own the account and the payment method, and give the agency delegated access.

Asset Type	Legacy Bundled Approach	Unbundled Standard
Domain registration	Agency buys on its own registrar account and charges the client a flat fee.	Client registers on a client-owned registrar account; agency gets delegated or team access where the registrar supports it.
Hosting	Agency hosts on a master reseller account and absorbs plan upgrades.	Site runs on a client-owned hosting account (for example WP Engine, Flywheel, AWS, or Vercel) with agency team access.
Premium plugins and modules	Agency uses a master license and absorbs vendor price changes.	Client holds individual licenses, or the agency resells licenses with automatic pass-through.
Usage-based SaaS (email, search, CRM)	Included in a generic “site maintenance” cap.	Billed directly to the client based on actual usage.

Step 3: Move to Pass-Through Plus a Management Fee

For stacks the agency curates itself (a CDN, a web application firewall, and a backup suite, for example), use a pass-through model:

Total monthly invoice = Actual third-party costs + Fixed management fee

Pass-through billing: Invoice the actual cost of the stack, with a defined handling fee if you want to cover the admin time.
Management fee: Charge a separate flat monthly fee (or hourly rate for out-of-scope work) for auditing, configuration, monitoring, and emergency response.

If a vendor raises its price by 15%, the client’s invoice reflects it and the agency’s labor margin is unaffected. Expect clients to scrutinize a rising invoice, so the vendor notices you forward become part of your credibility. Show them the source.

Transition Protocol for Existing Client Portfolios

Changing existing fixed-fee plans takes communication and a schedule.

Audit your portfolio. For every active retainer, map the actual hard costs (domains, hosting, licenses, usage-based services) against the monthly fee collected. Flag accounts below the gross margin target you’ve set.
List renewal dates and price-change dates. Record which assets renew when and where an announced vendor change lands (for example .net on March 1, 2027). Where it makes sense, renew early to lock in current wholesale pricing.
Give notice 60 days before each renewal. Send clients a clear explanation of the vendor adjustments, with the vendor’s own announcement attached.
Offer migration help. Provide a simple hand-off process to move domains and hosting accounts into client-owned accounts.
Frame it as ownership and transparency. For most clients, the pitch is that they hold direct ownership and control of their digital assets while you keep providing management, optimization, and oversight.

By unbundling third-party renewals from fixed-fee agreements, agencies stop absorbing vendor inflation, reduce their liability, and tie their revenue to what clients actually pay them for: professional expertise.

Originally published at https://instarenewal.com/blog/the-net-zero-retainer-fallacy-why-bundling-renewal-costs-into-fixed-fee

The “Broken Handshake” Liability: Why Agency Agreements Must Define Post-Termination Asset Custody

Memo — Sat, 31 Oct 2026 02:05:31 +0000

When an agency retainer ends, the digital relationship often doesn’t. Long after the final invoice is paid, the agency may still be logged in, listed as an account owner or admin, or connected through live API keys and OAuth tokens to its former client’s systems. This article calls that leftover access orphaned administrative authority, and uses “Broken Handshake” as shorthand for the moment the commercial relationship ends but the technical one does not. Neither term is a legal standard.

The assets involved include domain registrars, cloud infrastructure (AWS, Google Cloud), ad platforms (Meta, Google Ads, TikTok), analytics and tag management, and SaaS and martech integrations. When the agreement says nothing about who holds these assets after exit, small lapses can cause real damage. A missed renewal notice, an unrevoked integration or an ad account stuck in the wrong portfolio can lead to a site outage, a data exposure or a lawsuit.

This article is general information, not legal advice. Outcomes depend on jurisdiction, the contract and the facts.

1. Anatomy of the “Broken Handshake”

In fast-moving agency work, access is granted informally to hit deadlines. At exit, offboarding is often treated as an administrative chore rather than a risk-control workflow. The gap between “contract ended” and “access actually transferred” is where problems start.

Common assets caught in custodial limbo

Domains and DNS: Agency-held registrar accounts (GoDaddy, Namecheap and others), DNS providers such as Cloudflare, and registrant records that point to the agency or an individual employee.
Advertising and marketing accounts: Meta business portfolios (formerly Business Manager), Google Ads manager links, TikTok ad accounts and programmatic platforms where the agency is the owner rather than a partner.
Cloud and hosting: AWS and Google Cloud accounts or organizations, WP Engine installs, and Vercel or Netlify team seats.
Analytics and tagging: Google Tag Manager containers, Segment workspaces, BigQuery datasets and Mixpanel projects.
SaaS and integrations: HubSpot, Salesforce Marketing Cloud, Zapier connections and OAuth tokens that link third-party apps to client data.

2. Ownership vs. Access: What Platforms Actually Allow

Many exit disputes come down to one question: was the asset created inside the client’s account, or the agency’s? Platform rules make the answer hard to change later.

Meta. Meta distinguishes between giving someone access to an asset and owning it, and partner access never transfers ownership. Meta’s documentation states that an ad account can belong to only one business portfolio. An ad account that is created in, or claimed into, a portfolio may be permanently tied to it and can’t be moved to another. Meta also notes that accounts whose payment methods are managed by a third party can’t be moved. In practice, if an agency created the ad account inside its own portfolio, the client usually can only receive it as a shared asset. The usual workaround is a new ad account in the client’s portfolio, which costs the client its history inside the old account. Pixels and datasets follow the same one-owner model. Agencies that handle these cases report that ownership transfers go through Meta support and can take days, not minutes.

Google Ads. The model is friendlier to clients. Linking an existing account to an agency’s manager account does not by itself hand ownership to the manager. An administrator on the client account can remove a manager’s access, and Google’s documentation says client-account users can always unlink a manager that holds ownership. The practical caution is that resources defined at the manager level, such as shared audience lists or conversion tracking, may not travel with the client account. Check those before anyone unlinks during a dispute.

Domains. Since August 21, 2025, ICANN’s Registration Data Policy has made the registrant contact the only required contact for most gTLDs. Administrative, technical and billing contacts are no longer required, and many registrars have deleted that data. For most domains, control now comes down to two things: who is named as registrant, and who holds the registrar account login. Timing also matters. Under the Transfer Policy in effect as of September 2026, a material change of registrant can trigger a 60-day inter-registrar transfer lock unless the registrar offers and the holder uses an opt-out. ICANN’s Board approved a set of Transfer Policy Review recommendations on June 7, 2026, but implementation was still pending at the time of writing. Agencies should therefore plan registrant changes well before the exit date and confirm current rules with the registrar.

3. Legal Exposure When the Contract Is Silent

When a contract doesn’t allocate custody, courts fall back on general doctrines. The results vary by jurisdiction and are hard to predict.

Apparent authority mostly exposes the client

Under the Restatement (Third) of Agency §3.11, ending an agent’s actual authority does not by itself end its apparent authority. Apparent authority lasts until it is no longer reasonable for a third party to believe the agent is still authorized. This mainly protects third parties who dealt with the agent and received no notice of the termination. The practical consequence is that a client can remain bound by a former agency’s dealings with vendors who were never told the relationship ended. The agency’s exposure is different: acting beyond its actual authority after termination can make it liable to the client. Both sides therefore benefit from notifying vendors, and from the agency removing itself as the contact on the client’s accounts.

Illustrative scenario (hypothetical, not a reported case): A registrar’s renewal notice goes to a former agency’s shared inbox months after the contract ended. Nobody acts on it, and the domain lapses. The client’s loss, and any dispute over who was responsible for the notice, would turn on the contract and the facts. A clear transfer clause removes that ambiguity.

Courts treat digital assets as property

Courts have increasingly applied ordinary property doctrines to digital assets:

Kremen v. Cohen, 337 F.3d 1024 (9th Cir. 2003): The Ninth Circuit held that a domain name is intangible property that can support a conversion claim under California law.
Salonclick LLC v. Superego Management LLC, 2017 WL 239379 (S.D.N.Y. Jan. 18, 2017): A company alleged that its former marketing contractor kept control of its domains and social media accounts after the relationship ended. At the motion-to-dismiss stage, the court let conversion and replevin claims proceed. It also let a breach-of-fiduciary-duty claim proceed against the independent contractor, based on allegations that it had access to sensitive accounts and a corporate credit card. These were allegations and not final findings.
MasterMind Involvement Marketing, Inc. v. Art Institute of Atlanta, LLC, 389 F. Supp. 3d 1291 (N.D. Ga. 2019): A social media agency sued to collect unpaid fees. The defendants counterclaimed and sought an injunction for the return of 16 social media accounts. The court granted the injunction, ordered the agency to hand over login information and control, and found a substantial likelihood of success on a conversion claim and irreparable harm to the clients’ business and reputation. The agency’s own fee claim did not stop the order.
JLM Couture, Inc. v. Gutman, No. 21-2535 (2d Cir. Jan. 17, 2024): This is a counterweight. In a dispute between a fashion company and its former designer, the Second Circuit vacated an order giving the company exclusive control of social media accounts. It said ownership analysis should treat accounts like other property and begin with who the original owner was. Courts do not hand accounts to whoever asks first, so documenting who created and owns each asset from day one matters.

Withholding access over unpaid fees is high-risk

Some agencies hold accounts back to pressure a client to pay a disputed invoice. MasterMind shows how poorly that can go. Absent an express contractual right, withholding client-owned accounts invites conversion and related claims, and courts can order the assets returned on an expedited basis while the fee dispute continues. A better course is to pursue the fee through the contract’s normal remedies and keep custody of the assets out of the dispute.

4. Operational Risk Analysis

Risk vector	Typical cause	Commercial impact
Administrative lockout	Agency holds the only owner or super-admin role	Client cannot add staff, change billing or update security settings
Orphaned billing	Agency or former-employee payment method remains on a client ad account or domain	Unintended charges, failed payments that pause campaigns, disputed reimbursements
Stale integrations	OAuth tokens, API keys or service-account keys never revoked	Continued data access by a party with no business need; a larger attack surface if the agency is breached
Unreachable renewals	Vendor notices go to agency staff or shared inboxes	Domain, SSL or license lapses nobody sees until the site breaks
Data-protection exposure	Client personal data left on agency servers, cloud storage or test environments	Possible GDPR and, from 2027, DPDP compliance problems (see Section 5)

5. Data Protection Obligations at Exit

Asset custody and data custody overlap. Under GDPR Article 28(3)(g), a processor must, at the controller’s choice, delete or return all personal data after the end of the services and delete existing copies unless Union or Member State law requires storage. An agency processing client personal data typically falls under this rule. The agency’s exit checklist should therefore include a documented return-or-delete step and written confirmation.

India’s Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 were notified in November 2025 and are being phased in. Most substantive obligations, including security safeguards and erasure and retention rules, are scheduled to take effect around May 2027. In early 2026 MeitY proposed shortening some timelines for larger data fiduciaries, so check the current schedule. Agencies serving Indian clients should build deletion and return steps into their exit process now.

6. Contractual Solutions: Drafting the Asset Custody Clause

Treat asset custody and transfer as a core pillar of the agreement, alongside IP, payment and confidentiality.

Key terms to define

Ownership from day one. Require that assets be created in the client’s own accounts (the client’s registrar account, business portfolio and cloud organization) with the agency as a partner or user. Because platforms such as Meta don’t allow ad accounts to be moved between portfolios, this is far easier to get right at kickoff than at exit.
Definition of client assets. List what counts (domains, ad accounts, tag containers, hosting, repositories, SaaS subscriptions) and separate it from agency-owned proprietary tools.
Transfer duty and timeline. Define who receives ownership, administrative and billing roles, and within what window.
Sequencing. The agency removes its own access only after the client confirms it holds full control.
No withholding. Fee disputes are resolved through the contract’s payment remedies and never by suspending or retaining client assets.
Revocation of integrations. Require revocation of API keys, OAuth tokens, webhooks and SSH keys, and removal of agency payment methods.
Data return or deletion. Require return or deletion of client data on the client’s instruction, with written confirmation.
Defined liability cutoff. Limit the agency’s responsibility for events after a completed transfer, with carve-outs for gross negligence and willful misconduct.

7. Model Contractual Clauses

Illustrative language only. Have counsel adapt it to your jurisdiction and governing law. Some provisions, especially deemed-acceptance and liability-release terms, may not be enforceable everywhere.

Post-Termination Asset Custody

1. Client Digital Assets. “Client Digital Assets” means all domain names, advertising accounts (including Meta, Google Ads and TikTok), analytics properties, tag management containers, hosting and cloud accounts, source code repositories and third-party SaaS subscriptions registered, created or managed for Client during the Term.

2. Ownership at Creation. Agency shall create or register Client Digital Assets in Client’s name or within accounts owned by Client, and shall not register them in Agency’s own name or portfolios without Client’s written consent. Where a platform does not permit transfer of an asset created in an Agency-owned account, Agency shall disclose this in writing before creation and, on termination, provide continued access and a full data export.

3. Transfer Duty. Within ten (10) business days after the effective date of termination (the “Transition Period”), Agency shall:

(a) reassign all owner, administrator, registrant and billing roles on Client Digital Assets to Client’s designated representative;

(b) remove Agency’s own payment methods from Client Digital Assets;

(c) revoke all API tokens, webhooks, service accounts and third-party integrations connecting Agency systems to Client Digital Assets;

(d) remove Agency user accounts and external roles only after Client confirms in writing that it holds full administrative control of the relevant asset; and

(e) provide written confirmation of the foregoing.

4. No Withholding. Agency shall not suspend, withhold, restrict or condition the transfer of any Client Digital Asset because of a dispute over fees or any other claim. Agency’s remedies for non-payment are limited to those otherwise available under this Agreement.

5. Data Return or Deletion. At Client’s election, Agency shall return or securely delete all Client data, including personal data, and certify completion in writing, except where applicable law requires retention.

6. Client Cooperation and Acknowledgment. Client shall designate a recipient within three (3) business days after notice of termination and shall sign an Acknowledgment of Transfer within three (3) business days after receiving each asset. If Client fails to designate a recipient or accept a transfer after two written notices, Agency’s transfer obligation for the affected asset is satisfied on documented written tender.

7. Cessation of Custody; Limitation. On completion of the transfer (or the end of the Transition Period, if Agency has met its obligations under Sections 3 to 6), Agency’s custodial and administrative duties regarding the transferred Client Digital Assets end. Agency is not liable for downtime, expiration, suspension, loss or security incidents affecting those assets after that date, except to the extent caused by Agency’s gross negligence, willful misconduct or breach of this clause.

8. The Agency Offboarding Framework: Operationalizing the Contract

A clause only works if someone executes it. This four-phase checklist uses the same timeline as the model clause.

Phase	Trigger	Key actions
1. Audit and inventory	Termination notice	Map every account, SSO login, OAuth grant, API key and billing method. Classify each asset as client-owned or agency-owned, and record where the platform won’t allow a transfer (for example, a Meta ad account sitting in the agency’s portfolio). Confirm who receives vendor notices.
2. Ownership transfer	First days of the Transition Period	Update registrant and registrar-account ownership, allowing for the registrant-change lock described in Section 2. Invite client admins to Meta, Google, cloud and tag platforms. Get the client’s written confirmation of full control.
3. Access revocation	Client confirms control	Remove agency seats and secondary emails. Revoke OAuth tokens, API keys, webhooks and SSH keys. Remove agency payment methods. Notify third-party vendors of the contact change.
4. Sign-off and data disposition	End of Transition Period	Sign an Acknowledgment of Transfer. Return or delete client data per the client’s election and applicable law. Issue written confirmation.

9. Summary Comparison: Traditional vs. Asset-Custody Contracts

Contract feature	Traditional agency contract	Asset-custody contract
Post-termination scope	Covers deliverables and final billing	Defines who owns each asset and when roles transfer
Third-party accounts	Silent; agency staff remain on domain, hosting and ad accounts	Requires transfer of owner and admin roles within a set window
Asset creation	Agency may create assets in its own accounts	Assets are created in client-owned accounts from day one
Integrations	Tokens and webhooks stay active until someone notices	Requires systematic revocation and written confirmation
Fee disputes	Withholding access is possible and risky	Prohibits withholding; fee claims go through normal remedies
Liability	Open-ended claims of negligence, conversion or breach of fiduciary duty	Clear cutoff after a completed transfer, with carve-outs

Defining post-termination custody replaces an informal exit with a predictable process. Spelling out ownership at creation, transfer timelines, revocation duties and data return or deletion reduces the risk of lockouts, lapsed domains, data exposure and disputes for both agencies and clients.

Originally published at https://instarenewal.com/blog/the-broken-handshake-liability-why-agency-agreements-must-define-post

The “Broken Handover” Audit: What to Do When a Client Fires Another Agency and Leaves You With Unmanaged DNS

Memo — Fri, 30 Oct 2026 02:05:58 +0000

Winning a new client account often feels like a victory, until the onboarding kickoff exposes a looming infrastructure problem.

The client has recently parted ways with their former agency, sometimes on bad terms. The previous agency may have deleted the management portal, kept the domain registrar login, or left a web of custom DNS records scattered across third-party cloud accounts. Often there was no malice, only years of neglect. The client’s marketing leads don’t know where the domain is registered, who holds administrative access, or why transactional emails are landing in spam.

We’ll call this scenario a Broken Handover.

Inheriting unmanaged DNS is high-stakes for any agency or managed service provider (MSP). A single mistake during onboarding can mean website downtime, broken SaaS integrations, lost email, or lasting reputational damage.

This triage guide walks through an audit framework for securing, reconstructing and taking control of an unmanaged DNS setup while keeping the risk of disruption as low as possible. Where a step depends on a standard, a deadline or a vendor policy, the current rule is noted so you can verify it against your own environment.

Before You Touch Anything

Get written authority. Registrars, DNS hosts and cloud vendors will want proof that you act for the legal domain owner. Get a signed letter of authority or an email from someone with signing power at the client.
Snapshot the current state. Save timestamped output of dig queries for the apex and www, plus every MX, TXT and NS record. Screenshot whatever dashboards you can reach. This is your rollback reference and your evidence if anything is later disputed.
Freeze change requests. Ask the client to pause new site launches, email platform changes and marketing-tool onboarding until the audit is done.

Phase 1: Triage & Emergency Stabilization (Hours 0–4)

Your priority is stabilization. Before changing any record, establish who controls what, and make sure a former vendor can’t sabotage the account.

┌─────────────────────────────────────────────────────────┐
│               DNS STABILIZATION TIMELINE                │
└─────────────────────────────────────────────────────────┘

  Hours 0–4      Establish Authority & Lock Registrars
  ┌──────────┐   • Get written client authority
  │ PHASE 1  │   • Identify registrar & authoritative NS
  └────┬─────┘   • Secure registrar login, MFA, locks
       │
  Hours 4–12     Reconstruct the Zone
  ┌────▼─────┐   • Build record inventory from multiple sources
  │ PHASE 2  │   • Audit mail records (SPF, DKIM, DMARC)
  └────┬─────┘   • Lower TTLs to 300s (if old DNS host reachable)
       │
  Hours 12–24    Eliminate Takeover Risks
  ┌────▼─────┐   • Find dangling CNAMEs, stale IPs, lame NS
  │ PHASE 3  │   • Reclaim or delete orphaned records
  └────┬─────┘   • Keep dead records out of the new zone
       │
  Day 2+         Stage, Cut Over, Verify
  ┌────▼─────┐   • Stage new zone & CAA records
  │ PHASE 4  │   • Handle DNSSEC DS records first
  └──────────┘   • Switch NS; keep old zone live 48–72h

1. Identify Ownership & Location

Don’t rely on the client’s memory. Establish ground truth from the public DNS and registration data:

# Registration data (registrar, dates, status codes, nameservers)
whois example.com

# Delegation as published by the parent zone
dig example.com NS +short
dig +trace example.com NS

# Does each listed nameserver actually answer for the zone?
dig @ns1.provider.com example.com SOA +norec

You can also use ICANN’s lookup tool. On 28 January 2025, gTLD registries and registrars stopped being required to offer WHOIS, except for .com, .name and .post, and RDAP is now the required protocol, according to ICANN’s RDAP FAQ. WHOIS may therefore be unavailable for some TLDs, and ccTLDs follow their own rules. Registrant details are often redacted. The registrar, creation date, nameservers and EPP status codes are generally still visible.

Two different things need answering:

The domain registrar: where the name is registered (for example Namecheap, GoDaddy, Cloudflare Registrar or Amazon Route 53 registered domains).
The authoritative nameservers: where the live DNS zone is actually hosted (for example Cloudflare, Route 53, DigitalOcean, or a server owned by the former agency).

These are often different companies. If the client controls the registrar but the former agency controls the DNS host, you can still re-delegate the domain to a new provider without the agency’s cooperation. You just need a complete, reconstructed zone ready first.

2. Secure Registrar Access & Apply Locks

If the client still holds the registrar credentials, log in and lock things down immediately:

Strengthen authentication. Enable the strongest MFA the registrar supports, preferably FIDO2/WebAuthn security keys or passkeys where offered, otherwise an authenticator app (TOTP). TOTP is not hardware-based. Remove SMS-based recovery wherever possible.
Clean up contacts. Remove recovery and notification emails that belong to the former agency, and replace them with a client-owned role mailbox. Contact changes can trigger side effects (see the next section).
Enable registrar locks. clientTransferProhibited blocks transfers to another registrar, and clientUpdateProhibited and clientDeleteProhibited add further protection. These are registrar-level locks that anyone with account access can toggle, so they’re only as strong as the account’s security. For high-value domains, ask whether the registrar offers registry lock, which requires out-of-band verification for changes.
Verify new contact emails. After you change registrant contact data, the registrar typically sends a verification email. If it isn’t confirmed within the deadline (commonly 15 days), the domain can be suspended. Make sure someone monitors that inbox.
Mind the change-of-registrant lock. Under the current ICANN Transfer Policy, a material change to registrant information can trigger a confirmation step and a 60-day inter-registrar transfer lock. Some registrars offer an opt-out before you make the change, but they aren’t required to. If you plan to move the domain to a different registrar, ask about the opt-out first. ICANN’s Board approved 47 Transfer Policy Review recommendations on 7 June 2026, but implementation was still pending as of September 2026. Check the policy in force when you act.

3. What to Do If You’re Locked Out Entirely

If the former agency registered the domain in its own name or won’t hand over credentials, escalate in this order:

Document your claim. Gather invoices and card statements showing the client paid for registration and renewals, the signed contract and any IP-ownership or asset-transfer clauses, business formation documents, and any trademark registrations.
Make a written demand. Send a formal request to the former agency citing the contract. Many handovers are resolved at this stage.
Go to the registrar. Ask the registrar about its account-recovery or ownership-verification process, and submit your documentation. Processes and evidentiary requirements vary, and some registrars will only act on a court order. ICANN itself does not resolve individual domain disputes, and ultimately courts decide ownership rights.
Consider a formal proceeding, with counsel. The UDRP lets a complainant seek transfer of a domain, but it requires showing that the domain is confusingly similar to a trademark the complainant has rights in, that the registrant lacks legitimate interests, and that the domain was registered and used in bad faith. ICANN’s own ombudsman describes this as a narrow category to approach with caution. A dispute that is really about a contract may fit poorly. In the U.S., the Anticybersquatting Consumer Protection Act offers a court route. Country-code registries run their own schemes. For example, Nominet’s Dispute Resolution Service for .uk domains has been used to recover domains from web developers who registered them on a client’s behalf.
Prepare the replacement setup in parallel. Build and test the new zone and email configuration now, so you can cut over quickly the moment control is restored.

Phase 2: Complete DNS Zone Reconstruction (Hours 4–12)

If the former agency won’t provide a clean zone export (a BIND-format file), reconstruct the zone from several sources. Start by asking politely for an export anyway. If the DNS host still lets you in, export from there.

Be skeptical of automatic importers. DNS providers’ onboarding scans query common hostnames and can miss records, including DKIM selectors and anything created by a wildcard. Cloudflare’s own guidance is to review scan results manually and add anything missing before changing nameservers. A BIND zone-file import followed by a record-by-record comparison is more reliable.

You can try a zone transfer against each authoritative server, though well-configured servers refuse it:

dig AXFR example.com @ns1.provider.com

Zone Reconstruction Matrix

Record Type	Purpose	How to Recover Unmanaged Entries
A / AAAA	Maps names to IPv4/IPv6 addresses	`dig` only answers for names you already know. Combine passive DNS history (SecurityTrails, VirusTotal), certificate transparency logs (crt.sh), the site’s sitemap and internal links, and the hosting control panel.
CNAME	Aliases one name to another, often pointing at SaaS or cloud apps	Enumerate subdomains with `subfinder` or `amass`, search crt.sh, and check each SaaS vendor’s custom-domain settings. Note that wildcard certificates can hide subdomain names in CT logs.
MX	Routes inbound email	`dig example.com MX +short`. Preserve priority values exactly. Compare against the mail provider’s admin console.
TXT	Email authentication, domain-verification tokens, ACME validation	`dig example.com TXT +short`, then compare against each vendor’s dashboard. Verification tokens for Google Workspace, Microsoft 365, Atlassian and others should be kept unless the service is retired.
SRV	Service locators for SIP, Teams/Skype federation, XMPP and others	Query known service labels, such as `_sip._tls` and `_sipfederationtls._tcp` for Microsoft 365 voice/Teams federation, or `_xmpp-server._tcp`. In Microsoft 365, Autodiscover is normally a CNAME (`autodiscover.outlook.com`), whereas `_autodiscover._tcp` SRV records appear in other Exchange setups.
CAA	Restricts which certificate authorities may issue certificates	`dig example.com CAA +short`. Record anything present before you change it.
NS	Authoritative nameservers, and delegated subdomains	`dig example.com NS`. Check for delegated child zones (for example `app.example.com` delegated to another provider) and recreate those delegation records.

Also look for _acme-challenge CNAMEs or TXT records. Certificate automation may depend on them, and with certificate lifetimes shrinking (see Phase 4) a missing validation record causes outages on a predictable schedule.

Deep-Dive: Auditing Email Authentication (SPF, DKIM, DMARC)

Email deliverability is often the first casualty of a bad handover. Mailbox providers have also raised the bar. Google and Yahoo began enforcing bulk-sender rules in February 2024, and Microsoft followed for Outlook.com consumer accounts from 5 May 2025. The rules cover senders of roughly 5,000 or more messages per day and require SPF, DKIM and at least a p=none DMARC policy.

# Current SPF record
dig example.com TXT +short | grep "v=spf1"

# DKIM selector records (selectors vary by sending platform)
dig google._domainkey.example.com TXT +short
dig selector1._domainkey.example.com CNAME +short
dig k1._domainkey.example.com CNAME +short

# DMARC policy
dig _dmarc.example.com TXT +short

Audit SPF. A domain may publish only one SPF record. Under RFC 7208, evaluation is limited to 10 DNS-querying terms (include, a, mx, ptr, exists and redirect) and two “void” lookups. Exceeding either causes a permanent error, so legitimate mail can fail SPF. Remove includes for services the client no longer uses, such as old Mailchimp or ActiveCampaign setups, and stale IP ranges.
Locate DKIM selectors. DNS cannot list selectors, so you can’t discover them by querying the zone. Find them in the s= tag of a DKIM-Signature header on real outgoing mail, or in each sending platform’s authentication settings. Common examples are google for Google Workspace, selector1 and selector2 for Microsoft 365, and k1 for Mailchimp. Mailbox-provider guidance sets 1024 bits as the minimum DKIM key length and recommends 2048 bits. Keys are generated by the sending service and you publish the record it gives you. A 2048-bit key exceeds the 255-character limit of a single DNS string, so it must be split into multiple quoted strings, which most DNS providers do automatically.
Set up DMARC monitoring. If the previous agency left DMARC at p=none, or none exists, publish a record that collects aggregate reports and review them before tightening. Move to p=quarantine, then p=reject, once all legitimate senders pass.

# Example baseline DMARC record for the audit phase
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@youragency.com"

DMARC’s specification changed in May 2026, when the IETF published RFC 9989, RFC 9990 and RFC 9991, replacing the original RFC 7489. The record version tag stays v=DMARC1, so existing records keep working. The pct, rf and ri tags were removed and a t testing flag was added, which is why the example above omits pct. Failure (ruf) reports are optional, are not sent by many receivers, and can include message content, so they aren’t a reliable audit tool. If your reporting address is on a different domain than the one being protected, the reporting domain may need to publish an authorization record. Most DMARC reporting services handle this for you.

Phase 3: Securing “Dangling” Records & Subdomain Takeovers (Hours 12–24)

A critical risk in an unmanaged handover is the dangling CNAME. The previous agency may have cancelled cloud services (AWS S3, GitHub Pages, Heroku, Azure, Shopify and others) without deleting the DNS records pointing to them.

┌─────────────────────────────────────────────────────────┐
│              SUBDOMAIN TAKEOVER MECHANICS               │
└─────────────────────────────────────────────────────────┘

 1. DNS Record Active         2. Cloud Service Cancelled
┌─────────────────────┐      ┌───────────────────────────┐
│ promo.example.com   │─────►│ example.s3.amazonaws.com  │
│ (CNAME Record)      │      │ (Deleted by Old Agency)   │
└─────────────────────┘      └─────────────┬─────────────┘
                                           │
 3. Attacker Claims Endpoint               │
┌──────────────────────────────────────────┴─────────────┐
│ Attacker creates a resource with the same name         │
│ Result: Attacker serves content from                   │
│ promo.example.com                                      │
└────────────────────────────────────────────────────────┘

This is not theoretical. Infoblox’s research into a threat actor it tracks as Hazy Hawk describes hijacked subdomains of organizations including the US CDC, Deloitte and UNICEF. The actor claimed abandoned cloud resources (such as S3 buckets and Azure endpoints) behind dangling CNAMEs and used them to distribute scams and malicious content. Infoblox’s May 2025 report noted that finding vulnerable records takes effort, since every cloud provider handles dropped resources differently and some, such as Azure, have built-in protections. Its recommendation is to remove DNS records whenever a cloud resource is shut down. An agency inheriting a client’s DNS should treat every dangling record as a defect, whether or not the provider is currently exploitable.

How to Audit for Dangling Records

Build the CNAME list. Pull every CNAME from your reconstructed inventory, including passive DNS and certificate-transparency results.
Test where each one points. A non-resolving target (NXDOMAIN) is a strong warning sign:

   while read -r host; do
     target=$(dig +short CNAME "$host" | head -1)
     [ -n "$target" ] || continue
     dig +short "$target" | grep -q . || echo "NO ANSWER: $host -> $target"
   done < subdomains.txt

Check the HTTP response. Where the target still resolves, look for “unclaimed” fingerprints. The community-maintained can-i-take-over-xyz list tracks these. For example, an S3 target returning NoSuchBucket (message: “The specified bucket does not exist”) is listed as vulnerable. GitHub Pages (“There isn’t a GitHub Pages site here”) and Heroku (“No such app”) are listed as edge cases, so verify before assuming either way.
Check the delegation itself. If a domain’s NS records point to a DNS provider where the zone no longer exists, whoever creates the zone there may be able to answer for your domain. This is called a lame delegation, and Infoblox ties it to what it calls Sitting Ducks attacks. Query each nameserver for the zone’s SOA. A REFUSED or SERVFAIL response, or an answer without the aa flag, means that server isn’t properly serving the zone.

Immediate Remediation

Delete any CNAME pointing to an unallocated third-party resource. Confirm in logs or with the client that nothing legitimate depends on it.
If the service is still needed, re-create the backend resource first, then point the record to it.
Remove stale A/AAAA records that point to decommissioned IP addresses, since reassigned IPs can serve someone else’s content.
Don’t import dead records into the new zone.

Phase 4: Re-Hosting & Cutover (Day 2 Onward)

Once the inventory is verified, move authoritative DNS to a provider your agency can manage, with proper access controls and an audit trail. Treat the provider’s SLA as a procurement factor. Route 53 advertises a 100% availability SLA, and Cloudflare provides an SLA on its Business and Enterprise plans but not on Free or Pro. An SLA is a service-credit commitment, not a guarantee that outages won’t happen.

Step 1: Lower Time-To-Live (TTL) Values

If you can still reach the old DNS provider, reduce TTLs on key records to 300 seconds at least one full old-TTL period before cutover. A common recommendation is 24–48 hours ahead. Lower TTLs mean record changes take effect faster.

Lowering your record TTLs does not speed up the nameserver switch itself. The delegation is cached according to the parent zone’s TTL, which for .com and .net is 172800 seconds (48 hours). Some large resolvers cap NS caching at lower values, but plan for the full window. If the former agency controls the DNS host and you can’t edit TTLs, you can still re-delegate, so plan for the slower switch.

Step 2: Stage the New Zone

At your new provider (for example Cloudflare, which assigns each zone its own pair of nameservers):

Create the zone and import records from your reconstructed BIND file, or enter them manually.
Decide proxy/CDN settings deliberately. Proxied records return the provider’s addresses, so differences in comparisons are expected. Leave mail-related hosts DNS-only.
Compare old and new answers for every name in your inventory, not just the apex:

# Compare record types between old and new authoritative servers
for t in A AAAA CNAME MX TXT SRV CAA; do
  echo "== $t =="
  diff <(dig @ns1.oldagency.com example.com $t +short | sort) \
       <(dig @<assigned-ns>.ns.cloudflare.com example.com $t +short | sort)
done

Step 3: Prepare CAA Records and Handle DNSSEC

CAA (Certification Authority Authorization). CAA records tell certificate authorities which of them may issue certificates for the domain. They are checked by CAs at issuance and don’t stop anyone who still has control of your DNS from editing them, so publish them after you’ve secured DNS control. Inventory every service that issues certificates for the client (hosting, CDN, SaaS custom domains) before restricting issuance:

example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issue "digicert.com"
example.com. IN CAA 0 iodef "mailto:security@clientdomain.com"

DNSSEC. If the domain currently has a DS record at the registry, changing nameservers without handling it can make validating resolvers return SERVFAIL for the domain. The safe sequence is:

Remove the DS record at the registrar.
Wait at least the DS TTL. Many guides recommend 24–48 hours.
Change the nameservers.
Once the new zone is serving correctly, enable DNSSEC at the new provider and publish its new DS record at the registrar.

This matters more than it used to. Since 15 March 2026, certificate authorities must validate DNSSEC when it is present for CAA and domain-control lookups (CA/Browser Forum Ballot SC-085v2). A broken chain of trust can therefore block certificate issuance and renewal, not just resolution.

Certificate lifetimes are also shrinking. Under CA/Browser Forum Ballot SC-081v3, the maximum validity for publicly trusted TLS certificates fell to 200 days on 15 March 2026, drops to 100 days on 15 March 2027, and reaches 47 days on 15 March 2029. Domain-validation reuse shrinks on the same schedule. Any certificate renewed by hand is a future outage, so move to automated renewal as part of the handover.

Step 4: Cut Over Nameservers at the Registrar

Log in to the registrar portal and open the nameserver settings.
Replace all old nameservers with your new provider’s assigned set. Don’t mix old and new.
Query the TLD’s servers and public resolvers to confirm the new delegation is visible.
Test web, email (send and receive, then check SPF/DKIM/DMARC results in message headers), and certificate renewal.
Keep the old zone live and unchanged for at least 48–72 hours so resolvers still holding the old delegation get consistent answers. Then decommission it.

Phase 5: Client Communication & the “Handover Report”

Non-technical stakeholders often don’t see why an infrastructure audit takes time or costs money. A structured DNS Health & Audit Report turns the triage into a clear business outcome.

Executive Summary Template

Client: [Client Name]

Date: [Date]

Prepared By: [Your Agency Name]

Audit Status: [e.g., DNS control re-established and migrated]

1. Critical Risks Identified & Resolved (edit to match your findings)

Security Risk: [e.g., CNAME records pointed to abandoned cloud resources, exposing the brand to subdomain hijacking.]

Deliverability Risk: [e.g., SPF exceeded the 10-lookup limit; DKIM keys were missing or 1024-bit; no DMARC record was published.]

Access Risk: [e.g., Registrar administrative rights were tied to former agency staff accounts.]

2. Actions Taken

Reconstructed the zone configuration, comprising [X] records.

Migrated authoritative DNS to [provider], which offers [SLA terms, if any].

Enabled [MFA method] and registrar locks on the domain account.

Published CAA records and aligned SPF/DKIM/DMARC email authentication.

3. Outstanding Items & Recommendations

[e.g., Move DMARC from monitoring to enforcement after reviewing 30 days of reports.]

Master Checklist: Unmanaged DNS Rescue Audit

Use this checklist internally whenever you onboard a client with an abandoned or unmanaged DNS setup.

Access & Authority
- Obtain written authority from the client
- Identify the registrar and authoritative nameservers (RDAP/WHOIS, dig)
- Confirm each listed nameserver answers authoritatively for the zone
- Reset administrative and recovery contacts to client-owned addresses
- Enable the strongest available MFA; remove SMS recovery
- Enable registrar locks (clientTransferProhibited and related)
- Confirm registrant-email verification is completed
Zone File Reconstruction
- Request a zone export; attempt AXFR; import any BIND file
- Query active A, AAAA, CNAME, MX, TXT, SRV and CAA records
- Search certificate transparency logs (crt.sh) for hidden subdomains
- Pull historical records from passive DNS databases
- Check for delegated child zones and ACME validation records
Email & Deliverability Hardening
- One SPF record, within the 10-lookup and 2-void-lookup limits
- Locate DKIM selectors from message headers and sending platforms; use 2048-bit keys
- Publish DMARC with aggregate (rua) reporting; plan the move to enforcement
Vulnerability Remediation
- Scan for dangling CNAMEs pointing to unclaimed cloud hosts
- Check for lame delegations
- Remove stale A/AAAA records pointing to decommissioned IPs
- Leave dead records out of the new zone
Migration
- Lower TTLs on the old zone to 300 seconds 24–48 hours ahead (if accessible)
- Stage the new zone and compare every name against the old servers
- Remove the DS record, wait out its TTL, then change nameservers
- Verify web, email and certificate renewal after cutover
- Re-enable DNSSEC with the new provider’s DS record
- Publish CAA records after DNS control is secured
- Keep the legacy zone live for 48–72 hours after cutover

Originally published at https://instarenewal.com/blog/the-broken-handover-audit-what-to-do-when-a-client-fires-another-agency-and

The Multi-Tenant Licensing Crisis: Tracking Per-Seat vs. Per-Site Agency Tooling

Memo — Thu, 29 Oct 2026 01:59:50 +0000

Executive Summary

For years, many WordPress agencies built their margins on “unlimited site” developer licenses. One agency key, a standard plugin stack and a few hundred client sites was a workable model, and vendors encouraged it.

The picture in late 2026 is more mixed than “unlimited licenses are gone.” Several vendors have retired or capped their unlimited tiers. Others still sell them. Either way, the pricing metric now drives agency margin, whether it counts sites, seats, or both.

WP Rocket began phasing out its Infinite plan in 2025 and replaced it with Multi tiers of 50, 100 and 500 sites.
Astra announced in April 2025 that it no longer offers unlimited-site licenses.
Elementor now lists Essential, Advanced Solo, Advanced, Expert and One plans plus a One Agency tier. According to a September 2026 pricing roundup, the older Studio and Agency plans were removed from its price list.
ACF PRO, Gravity Forms and WPML still sell unlimited-site agency tiers, at $249/year, $259/year and €199/year respectively.

The core operational problem is unchanged. When a client leaves, a license key often stays active on a site the agency no longer earns from. It consumes a site slot, can push you into a more expensive tier at renewal, and can leave a client’s site tied to a key the agency should no longer control.

Unmonitored keys on offboarded sites create two risks:

Margin leakage: paying for site slots or seats that no longer produce revenue.
Compliance and continuity risk: running vendor licenses on sites outside your contract, and cutting off a former client’s access to updates without warning.

This article covers how per-seat and per-site pricing differ, what vendors actually do when licenses lapse, and a practical framework for auditing and governing licenses across client environments.

1. The Anatomy of Multi-Tenant License Leakage

When an agency builds dozens or hundreds of sites on a standard stack, developers often paste the agency’s key into each site’s settings. The key can also end up in wp-config.php, a deployment blueprint or a shared password manager.

Agency master license (site-capped tier)
  ├── Active client (retainer paid)       → key active, generating revenue
  ├── Offboarded client site ("ghost")    → key active, no revenue
  └── Staging / dev instance              → may or may not count against the cap,
                                            depending on the vendor's detection rules

The “Ghost Site” Problem

Offboarding checklists usually cover credentials, DNS and hosting. Application-level license activations are easy to forget. They live in the database, in wp-config.php or in environment variables, and they stay registered on the vendor’s side until someone deactivates them.

If a former client moves the site to a new host with the key still in place, the vendor’s licensing system can keep counting that domain against the agency’s allocation.

How Silent Margin Drift Happens

Tier selection at renewal: WP Rocket’s transition of Infinite customers shows how site count can drive price. Its email to customers said the Infinite license would move to a Multi tier based on the customer’s current website count, excluding staging sites. In the example shared publicly, an agency was moved to Multi 500, with a regular price of $599/year. Ghost sites inflate that count.
Hard activation caps: ACF PRO’s Freelancer tier covers 10 sites, and Agency covers unlimited. A published agency case study describes an “Activation limit reached” error when an additional site was activated. Hitting a cap with ghost sites on the account means blocked activations for live projects, or a forced tier upgrade.
Per-seat creep: Seat-based tools such as Figma, Asana and HubSpot charge per user. Former contractors or client staff left active in shared workspaces add cost month after month until someone audits the user list.
Staging and dev sites: Vendors handle these differently, so assuming they are free is risky. ACF PRO and WPML exclude recognized staging and development sites, but ACF’s detection depends on hostname patterns. A published ACF license walkthrough notes that a staging copy under a path such as /staging on the production domain is treated as production. WP Rocket’s FAQ says local domains don’t count and that subdomains and subfolders share one license under one top-level domain.

2. How Vendor Licensing Actually Behaves

Public documentation is less dramatic than “audits and blacklists.” In practice, the documented consequences of license problems are mostly about updates, support, new activations and tier changes, not sudden site breakage.

Gravity Forms: If a license expires, the plugin and add-ons stay installed and keep operating. You can no longer download the core plugin or add-ons, you see expiry reminders in the admin, and you can’t use that key to register a new site, even when restoring a backup. Gravity Forms also warns that an un-updated installation may eventually fail in unpredictable ways as WordPress and integrations change.
WPML: If you don’t renew, you can’t update WPML to new versions.
WP Rocket: The Multi license requires yearly renewal for continued access to support and updates.
ACF PRO: A WP Engine community thread quotes ACF’s documentation as saying field data outside the ACF admin screens isn’t affected by license status. The same thread’s answers suggest that revoking a key you share across sites is a coarse tool, and that having clients buy their own license avoids the problem.

Why Licensing Terms Have Tightened

Two documented reasons stand out:

Incentive misalignment on unlimited plans. A Freemius analysis argues that with an unlimited license, the vendor wants to minimize abuse of the agency’s key while the agency has no reason to care about site count. WP Rocket’s own customer notice said it had offered the Infinite license for over a decade before phasing it out.
Ownership and strategy shifts. ACF was acquired by WP Engine in 2022. WP Engine has been majority-owned by private equity firm Silver Lake since a $250 million investment in 2018. In October 2024, WordPress forked ACF’s free plugin into Secure Custom Fields. The dispute is a reminder that a plugin’s ownership, update channel and licensing can change quickly.

Each vendor’s terms of service define its enforcement rights, so read them directly. This article found no vendor publicly documenting retroactive invoicing for excess site activations, so budget for the documented behaviors above rather than for audit penalties.

The Real Operational Risks

Lost update access: On a lapsed or reassigned key, a client’s site can’t pull updates. For a security-critical plugin, that gap matters. Gravity Forms’ July 2025 supply-chain incident is a reminder of how important clean, current plugin sources are. Malicious code was found in manually downloaded versions 2.9.11.1 and 2.9.12 from the official download page on July 9–10, 2025, and Gravity Forms said its licensing and update API was not compromised.
Blocked new activations: An expired or capped key can block you from licensing a new client site in the middle of a launch.
Reputation and support load: Clients who see expired-license notices in their admin will ask the agency about them, whether or not the site still works.

3. Per-Seat vs. Per-Site: A Structural Comparison

Criteria	Per-Seat (user/operator)	Per-Site (domain/installation)	Hybrid (seat + site limits)
Billing metric	Number of user accounts.	Number of sites or domains activated.	User cap plus site limit.
Typical examples	Figma, Asana, HubSpot	ACF PRO, Gravity Forms, WPML, Elementor, WP Rocket	Plans combining both metrics
Margin effect	Overhead tied to team and contractor headcount.	Closer to a per-client cost, so it can be re-billed.	Needs allocation per client contract.
Offboarding failure mode	Unused seats keep billing.	Ghost sites consume capacity or push you to a higher tier.	Both failure modes at once.
Main audit task	Reconcile the user list against current staff and contractors.	Reconcile the activation list against active client domains.	Do both.

4. Illustrative Math: What Ghost Sites Can Cost

The numbers below are a hypothetical model, not a measured industry average. Substitute your own vendor tiers and churn rate.

Assumptions: an agency runs 150 live client sites, offboards 20% of clients each year (30 sites) and adds 30 new ones. No keys are deactivated at offboarding.

Year	Live client sites	Activated sites on vendor account	Ghost sites
1	150	150	0
2	150	180	30
3	150	210	60

By year 3, 60 of 210 activations (about 29%) belong to former clients.

Whether that costs money depends entirely on the vendor’s tiers. Take a purely hypothetical per-site vendor with a 200-site tier at $400/year and a 500-site tier at $700/year. Crossing 200 activations means paying the higher tier, an extra $300/year for ghost sites, and that excess would recur every year until the keys are cleaned up.

Check your actual contracts. If a vendor sells an unlimited tier, as ACF, Gravity Forms and WPML still do, ghost sites may cost nothing in license fees, though they still carry the security and ownership risks above. The place where ghost-site math bites hardest is capped tiers such as WP Rocket Multi (50/100/500) and Elementor Expert (25).

5. A Framework for License Governance

Phase 1: Ingestion          Phase 2: Deployment          Phase 3: Offboarding
• Central key inventory     • Keys supplied via config   • Deactivate site activations
• Client ID binding         • Environment scoping        • Remove keys from client host
• Renewal dates tracked     • Staging naming rules       • Notify client of next steps

Phase 1: Keep Keys Out of Site Settings Where You Can

Several vendors support defining the key in code:

ACF PRO supports an ACF_PRO_LICENSE constant in wp-config.php. ACF’s own code checks for the constant and activates the key.
Gravity Forms supports GF_LICENSE_KEY, but it only pre-populates the key at installation on a single-site install, or when new sites are created on a multisite network. It is not a way to change keys on already-installed sites.

// wp-config.php — read the key from the server environment rather than hardcoding it
define( 'ACF_PRO_LICENSE', getenv( 'AGENCY_ACF_LICENSE_KEY' ) );
define( 'GF_LICENSE_KEY',  getenv( 'AGENCY_GRAVITY_FORMS_KEY' ) ); // install-time only

Two caveats apply:

A constant means the master key lives on the client’s server. Offboarding must therefore include removing it from the host, because the key sits in the client’s environment either way.
Activation data may still be stored by the plugin after activation. Don’t assume a constant means nothing is written to the database.

For staging and development, don’t try to block vendor license calls in code. It is fragile and can break plugin behavior. Instead, use hostnames the vendor recognizes as non-production. For ACF, that means a staging subdomain, not a path on the production domain. Confirm each vendor’s current rules in its documentation.

Phase 2: Prefer Client-Owned Licenses Where It Makes Commercial Sense

A centralized proxy that forwards license checks under your master key is technically possible, but it is risky. It likely conflicts with vendor terms, depends on spoofable request data, and can break when a vendor changes its API. A better pattern for most agencies:

Use the agency tier for sites you actively manage and bill under a retainer.
Have clients buy their own license for tools you only configure once.
Use a vendor’s own multi-site management tools where one exists, instead of building around its licensing system.

Phase 3: Offboarding Checklist

When a client leaves, run license cleanup alongside access revocation:

Deactivate the site’s activation in each vendor account.
Remove license constants and keys from the client’s host or config.
Confirm the plugin shows an unlicensed state, with no agency key left in the database.
Send the client direct purchase links for the licenses they now need, and note the update implications from Section 2.
Update your inventory and close out any seat assignments in shared tools.

6. Contract and Record-Keeping Steps

Contract Language

Update client agreements to say who owns each license and what happens at termination. Have your lawyer review the wording. A starting point:

“Software licenses provided under the Agency Maintenance Retainer remain the property of the Agency. On termination, agency-provided premium software keys will be deregistered, and the Client is responsible for procuring its own licenses to continue receiving updates and support.”

A Central License Inventory

Keep one source of truth that ties each client, domain and vendor license together. A spreadsheet works at small scale. A record per client might look like:

{
  "client_id": "CLI-88402",
  "domain": "example-client.com",
  "contract_status": "Active",
  "licenses": [
    { "vendor": "Advanced Custom Fields", "tier": "Agency", "registered": "2025-01-15", "renewal": "2026-01-15" },
    { "vendor": "Gravity Forms", "tier": "Elite", "registered": "2025-01-15", "renewal": "2026-01-15" }
  ]
}

Reconciliation

Compare active client domains against each vendor’s activation list on a schedule. Most vendors expose activated sites in an account dashboard. Some may offer an API, so check each vendor’s documentation before building automation.

# Reconcile active client domains against a vendor activation export (CSV or API data)
ACTIVE_CLIENT_DOMAINS = {"alpha.com", "beta.io", "gamma.net"}

def find_orphaned_activations(vendor_activations):
    """vendor_activations: iterable of dicts with at least a 'domain' key."""
    return [a for a in vendor_activations if a["domain"] not in ACTIVE_CLIENT_DOMAINS]

# Example input, e.g. loaded from a vendor dashboard export
activations = [
    {"domain": "alpha.com", "activated": "2025-01-15"},
    {"domain": "former-client.com", "activated": "2024-03-02"},
]
for orphan in find_orphaned_activations(activations):
    print(f"REVIEW: {orphan['domain']} (activated {orphan['activated']})")

The script only flags candidates. A person should confirm each one before deactivating anything.

7. Conclusion: Turning License Governance into a Service

The shift from unlimited licenses to capped tiers is uneven across vendors. WP Rocket, Astra and Elementor have moved toward limits, while ACF PRO, Gravity Forms and WPML still sell unlimited agency plans. That unevenness is the reason to treat licenses as managed inventory: you need to know which of your vendors cap sites, which count staging, and what each does when a key lapses.

Agencies that track activations against active clients can avoid paying for ghost sites on capped plans and can plan renewals ahead of time. Once that inventory exists, it can also support a paid service. A license management retainer, where clients fund the premium tools their sites depend on, turns a hidden cost into a transparent line item.

Originally published at https://instarenewal.com/blog/the-multi-tenant-licensing-crisis-tracking-per-seat-vs-per-site-agency-tooling

The WebAssembly (Wasm) Module Expiry Trap: Tracking Client Edge Runtimes and Binaries

Memo — Wed, 28 Oct 2026 01:53:54 +0000

As compute moves closer to users, engineering teams and agencies increasingly ship WebAssembly (Wasm) modules to edge platforms such as Cloudflare Workers, Fastly Compute and Vercel Functions on the Edge runtime. Wasm offers near-native performance on compute-heavy work, lets teams use languages like Rust, Go and C, and runs inside a sandbox. It also creates an operational blind spot: a compiled Wasm binary has no expiry date, but the things it depends on do.

A .wasm file is an opaque artifact. It is tied to the compiler toolchain that produced it, the compilation target it was built for, the system-interface version it imports, the limits of the plan it is deployed on, and sometimes the signing identity used to approve it. When any of these moves, a module that ran for months can stop building, stop deploying or stop instantiating. Nothing in the binary itself warns you.

1. Anatomy of the Edge Wasm Lifecycle

Edge platforms remove server maintenance, but they move that complexity into the build pipeline and the artifact lifecycle.

[Source Code (Rust / Go / C)]
       │
       ▼  Compiler toolchain + compilation target
[Wasm Binary (.wasm)]
       │
       ▼  Optional: signing / attestation (your policy)
[Bundle or package uploaded to the platform]
       │
       ▼  Edge runtime (e.g. workerd, a Wasmtime-based host)
[Client execution]

The three major platforms handle Wasm differently:

Platform	How Wasm is delivered	Detail worth tracking
Cloudflare Workers	A `.wasm` file is imported into the Worker and instantiated with `WebAssembly.instantiate()`. Wrangler bundles any module ending in `.wasm` or `.wasm?module`.	Worker size is capped at 3 MB (Free) or 10 MB (Paid) after gzip, with a 1-second startup limit.
Fastly Compute	A package built by the Fastly CLI from your project, using the toolchain pinned in `rust-toolchain.toml` for Rust.	Fastly validates Rust versions against its SDK before supporting them.
Vercel Functions	Wasm works with the `edge`, `nodejs` and `bun` runtimes.	On the Edge runtime, `WebAssembly.instantiate` requires the Wasm source to come from an `import` statement.

Cloudflare’s limits page also lists 64 MB as the pre-compression bundle limit and notes that larger bundles can slow startup. The Wasm module ships inside the deployment, so a plan or bundle-size change can break a client’s Worker even if no code changed.

2. The Silent Vectors of Failure

Vector 1: Toolchain and target drift

Compilation targets get renamed and removed, and compiler releases occasionally produce bad output for a given platform. Real examples:

The WASI target rename. Rust 1.78 (May 2024) introduced wasm32-wasip1 as a rename of wasm32-wasi. Rust 1.84 (January 2025) removed the old target entirely, so projects still referencing wasm32-wasi failed after upgrading the compiler.
Fastly’s CLI target. Fastly’s Rust guide says CLI 11.0.0 and later supports only the wasm32-wasip1 target for Rust services, which requires Rust 1.78.0 or higher.
A compiler release that produced broken packages. Fastly’s Rust guide states that Rust 1.91.0 is not compatible with Compute and that 1.91.1 fixed the problem. The Fastly CLI was also updated to refuse builds with 1.91.0. Fastly’s engineering team had confirmed those packages would crash when handling incoming requests.

The last case shows the risk of floating toolchains. A pipeline that tracks the stable channel can pick up a compiler release the platform has not validated, and the failure appears at runtime rather than at build time. Fastly’s own guidance is to avoid updating Rust until Fastly releases an SDK that supports the new version.

Vector 2: WASI and runtime version drift

The system interface that Wasm modules import is still evolving, so modules built against older interface versions need deliberate migration.

WASI 0.3.0 was released on June 11, 2026. It moves async support into the Component Model itself, using built-in stream, future and async func primitives. The wasi:io package, which WASI 0.2 used for async, is replaced by these primitives.
Runtimes follow on their own schedules. The WASI project said Wasmtime 46 would ship WASI 0.3.0 with Component Model async enabled by default. The Wasmtime 46.0.0 release notes confirm that WASI 0.3.0 support and the component-model-async feature are enabled by default, and the release landed on June 22, 2026.
Not every host moves at the same time. Your edge platform’s runtime version, your local test runtime and your toolchain’s WASI target can each be on different interface versions.

Cloudflare mitigates part of this with compatibility dates. Its open-source workerd runtime is versioned by date, and the README states that updating workerd will never break your JavaScript code because Workers can pin to an older compatibility date. That promise covers the JavaScript API surface. It does not cover whether your Wasm module’s own imports still match what you built it against, so you still need to test the module itself.

Also note that Fastly’s original runtime, Lucet, reached end-of-life and was archived in March 2022. Its maintainers directed users to Wasmtime, which absorbed Lucet’s features. Documentation or blog posts that still refer to Lucet as a current edge runtime are out of date.

Vector 3: Signing identities and embedded time-limited material

None of the platform documentation reviewed for this article describes mandatory signature checks on uploaded Wasm modules. Signing is usually a policy your own team or a client’s security team adds to the pipeline. Where it exists, it creates its own expiry risk:

Module signatures are a proposal, not a universal standard. The WebAssembly module signatures proposal embeds signatures in the module so a runtime or deploy gate can verify them before instantiation. wasmsign2 is a reference implementation.
Keyless signing changes what “expired” means. Sigstore’s public Fulcio service issues short-lived certificates valid for 10 minutes, so verification has to prove the artifact was signed while the certificate was valid, using a timestamp or transparency-log entry, rather than checking whether the certificate is valid now. A verification step that checks the certificate’s validity at deploy time will reject every keyless-signed artifact.
Key-based signing carries a rotation burden. If your pipeline signs with a long-lived key or certificate and the deploy gate verifies it, an expired or rotated key will block deployments until the pipeline and the gate agree again.
Embedded time-limited material is a self-inflicted trap. If a build embeds an evaluation license or a time-limited credential, the module works until that timestamp passes. Platform documentation does not describe this behavior. It is a design choice, and it is easy to forget when a client engagement ends.

Vector 4: Plan tiers, size limits and startup budgets

Limits can change what a deployment is allowed to do. Cloudflare’s published limits differ between Free and Paid plans for Worker size (3 MB vs. 10 MB compressed), and both plans allow 1 second of startup time. A Wasm module that grew past the Free-plan cap, or a client account moved between plans, can produce a failed deployment that has nothing to do with your code. Separately, Workers that exceed their CPU time limit return Cloudflare’s Error 1102, which is easy to mistake for a runtime bug if you are not watching resource limits.

3. Best Practices for Mitigating Edge Wasm Drift

Pin compiler toolchains and targets. Avoid stable or latest in compilation stages. Commit a rust-toolchain.toml that names both the exact compiler version and the target:

  [toolchain]
  channel = "<version validated for your platform's SDK>"
  targets = ["wasm32-wasip1"]

Upgrade deliberately, after the platform vendor says the new version is supported.

Read release notes for your target and your runtime. Target renames (wasm32-wasi to wasm32-wasip1) and interface changes (WASI 0.2 to 0.3) are announced well in advance. Put the dates in your team’s calendar.
Run synthetic probes against deployed modules. Exercise a cold-start path for each deployed module on a schedule, so a broken package or failed instantiation shows up in your monitoring before a client reports it.
Keep artifacts in a registry with metadata. Store each build with its compiler version, target, WASI version, build date, size and the signing identity used. Cosign can store and sign Wasm modules as OCI artifacts, which gives you a versioned, verifiable record.
Make signature verification time-aware. If you use keyless signing, verify against the signing time evidenced by the transparency log or a timestamp authority rather than the current time. If you use long-lived keys, track their expiry dates like any other certificate.
Canary and roll back. Route a small share of traffic to newly compiled modules, and keep the previous known-good build deployable so a link or instantiation failure can be reversed quickly.
Record limits and plan tier per client. Note the Worker size, startup time and plan tier against each client deployment, and re-check them when the client’s account changes.

An inventory template for client edge deployments

For each client edge deployment, record:

Field	Why it matters
Platform and plan tier	Size and startup limits differ by plan.
Compiler version and target	Detects drift such as `wasm32-wasi` removal or an unvalidated Rust release.
WASI version and runtime version	Detects interface mismatches such as WASI 0.2 vs. 0.3.
Compatibility date (Cloudflare)	Shows which runtime behavior the Worker is pinned to.
Signing method and key/certificate expiry	Prevents deploy-gate failures.
Account owner and billing contact	Ensures someone can act when the platform plan changes.
Last successful cold-start probe	Shows when the module was last confirmed working.

4. Conclusion

WebAssembly at the edge delivers real speed and language flexibility, but a compiled module is not a write-once file. It depends on a compiler version, a compilation target, a system-interface version, a platform’s limits and, where you use it, a signing identity. Each of these has changed within the last two years, and several changes broke previously working builds. Teams that treat Wasm modules as living components, with pinned toolchains, recorded metadata and regular health probes, can avoid most of these failures and diagnose the rest faster.

The “Single Source of Truth” Fallacy: Why Shared Agency Spreadsheets Are Silently Costing You Clients

Memo — Tue, 27 Oct 2026 01:56:58 +0000

Picture this (an illustrative composite, not a single real case). It’s Thursday afternoon. Your agency’s largest retainer client, a $15,000/month enterprise account, emails your account director asking for an urgent breakdown of Q3 performance, media spend efficiency and upcoming deliverable timelines.

Within minutes, three team members scramble. The media buyer pulls data from the ad platform, the SEO lead exports numbers from Google Analytics, and the project manager opens “Master Client Tracker v4_FINAL_revised.”

By 4:00 PM, a polished deck lands in the client’s inbox. It contains a fatal flaw: the media buyer typed a figure into a cell by hand, the SEO lead missed a deleted row, and the project manager’s summary formula skipped half the deliverables. The numbers the client received contradict each other.

The client notices that traffic doesn’t line up with conversion spend. Internal panic follows, then finger-pointing. Trust erodes, and some months later the client moves to another agency.

If that sounds familiar, you’re in good company. Many growing agencies run on the same fragile arrangement: the shared agency spreadsheet as the “single source of truth.”

Spreadsheets are not the villain. They are flexible, familiar and often free, and plenty of small agencies run well on them. The problem is the gap between what a spreadsheet feels like (one authoritative record) and what it often is (a pile of copies, manual inputs and unreviewed formulas).

What the research says about spreadsheet errors

Spreadsheet risk is one of the better-studied topics in information systems. Professor Raymond Panko of the University of Hawaii has spent decades reviewing the research.

Errors are the norm, not the exception. Panko’s review of spreadsheet audit studies found errors in roughly 94% of the operational spreadsheets examined, with average cell error rates of around 5% in some of those studies. Other field audits found lower cell error rates, from under 1% to about 2.5%. The studies use different definitions of “error,” so treat any single percentage as indicative rather than precise.
Experience doesn’t make people immune. In a controlled comparison, undergraduates, MBA students with little spreadsheet experience and MBA students with 250+ hours of experience showed no significant difference in error rates.
Small error rates compound. Even a 1% error rate per cell makes a mistake somewhere in a large, interdependent model likely. Panko summarizes the position as “not whether there is an error but how many errors there are and how serious they are.”

Two well-documented incidents show how this plays out outside agencies:

JPMorgan’s “London Whale” losses (2012). The bank’s own task force report found that the value-at-risk model in its Chief Investment Office ran through a series of Excel spreadsheets completed manually by copying and pasting data between them. It also found a formula that divided by the sum of two rates instead of their average, which likely muted the calculated volatility by about half. The report described the manual process as “error prone.”
Public Health England (2020). The agency failed to include 15,841 positive COVID-19 cases, reported for 25 September to 2 October 2020, in its daily totals. Reporting pointed to lab results being loaded into the older .xls Excel format, which caps a sheet at 65,536 rows. Records beyond the cap were silently dropped. The modern .xlsx format allows 1,048,576 rows.

Neither case involved a marketing agency, and the stakes were far higher. The mechanics, though, are the ones your team faces: manual copy-paste, formulas nobody reviewed, and a tool that fails quietly rather than loudly.

Where spreadsheets start to strain

With three or four people and a handful of clients, a shared Google Sheet or Excel workbook is hard to beat. Strain tends to appear as accounts, channels and contributors pile up. There is no universal tipping point, and “15 clients” is a rule of thumb rather than a measured threshold. Several things push agencies toward the wall:

Multi-channel inputs: paid social, search, programmatic, email, analytics and CRM data, each with its own export format.
Shared team capacity: freelancers, designers, copywriters and media buyers split across accounts.
Varied billing structures: retainers, project add-ons, hourly overages and milestone pricing.

At that point you are asking a flat grid to model relationships: this client has these projects, which have these tasks, time entries and invoices. Spreadsheets can enforce some rules (data validation, protected ranges), but they have no native relational model. They can’t guarantee, for example, that every time entry points to a real project or that deleting a client doesn’t orphan its tasks.

Three silent killers of the spreadsheet “source of truth”

1. Version sprawl

A cloud spreadsheet edited live is, in principle, a single document. Sprawl creeps in when people export, download or duplicate it. By default in Google Sheets, even viewers and commenters can make a copy, download or print the file unless the owner switches that off. Meanwhile, files get emailed as Excel attachments or pasted into decks.

The symptom: several “current” versions in circulation, with tabs and exports that diverge.
The cost: budget changes, scope updates and campaign adjustments made on stale data while a colleague works from a different copy.

Version history helps (Google Sheets, for instance, lets you review and restore earlier versions), but it only tracks the file you’re looking at. It can’t reconcile copies that have already left it.

2. Broken formulas and hardcoded numbers

Spreadsheets depend on human precision: a misplaced range, a deleted header row, a sorted column that detaches a formula from its data.

The symptom: to hit a deadline, someone overwrites a formula with a typed-in number so the totals balance. Researchers who audit spreadsheets classify hardcoded numbers inside formulas as a poor-practice error even when the result happens to be correct.
The cost: the override becomes permanent, and later dashboards inherit it with no flag. Multiplied across many clients and trackers, leadership ends up making capacity and margin decisions on numbers nobody can fully trace.

3. Blunt access control

The common perception is that spreadsheets offer only “Editor” or “Viewer.” The reality is more nuanced. Google Sheets also has a Commenter role, and lets owners protect specific sheets or ranges and restrict who can edit them. Excel offers sheet and workbook protection as well. But these controls are limited:

Google’s own documentation says range protection shouldn’t be used as a security measure, because people with access can still print, copy, paste and export copies of a protected sheet.
Hiding a sheet isn’t protection either: all editors can unhide it.
Granting edit rights remains the path of least resistance, so many agencies give contractors broad access to avoid bottlenecks.

The cost: one accidental deletion of a sort order, a conditional-formatting rule or a key range can quietly break the tracker everyone relies on, often right before a client presentation.

The financial toll: reporting, retention and time

Reporting errors undermine trust

Enterprise clients compare your reports against their own ad dashboards and analytics. When your numbers disagree with what they see natively, the likely conclusion is that something is wrong with your process. There is no reliable public statistic ranking data discrepancies as a leading cause of client departures, so treat any claim that they are the “number one” trigger with suspicion. What the survey evidence does show is that communication and transparency matter. In Swydo’s analysis of why clients leave marketing agencies, 57% of departing clients cited poor communication and transparency, and price ranked only sixth (37%). Clients could name several reasons, so percentages exceed 100%. Setup’s 2024 Marketing Relationship Survey found dissatisfaction with delivery to be the top reason clients end relationships, cited by 48%. Both are vendor-published surveys, so read them as directional.

+-------------------------------------------------------------------+
|                    THE HIDDEN CHAIN REACTION                       |
|                                                                   |
|  [ Spreadsheet error / data silo ]                                |
|         ↓                                                         |
|  [ Inconsistent reporting to the client ]                         |
|         ↓                                                         |
|  [ Erosion of executive trust ]                                   |
|         ↓                                                         |
|  [ Higher churn risk and a costly replacement-client hunt ]       |
+-------------------------------------------------------------------+

Manual reporting eats billable capacity

Published estimates of time spent on manual client reporting vary enormously and mostly come from vendors who sell reporting tools. AgencyAnalytics cites 1.5 to 4 hours per client per reporting cycle. Other vendor surveys claim figures from a few hours to well over 10 hours per client per month. Your real number depends on how many data sources you pull and how much assembly is manual. The useful move is to measure it: have each account manager log reporting hours for two months, then multiply by your blended internal rate.

Scope creep hides in disconnected tabs

When time tracking, task lists and billing live in separate sheets, unbilled work is harder to see. No credible benchmark says agencies lose a specific percentage of retainer revenue to this. The practical fix is to compare hours logged per client against what the retainer covers each month, and to flag overruns while there is still time to act.

Moving from fragile sheets to a real single source of truth

You don’t need heavyweight enterprise software to escape the trap. A single source of truth is a design principle: each important fact is stored in one authoritative place, and everything else reads from it. In practice:

Use relational structures for operational data. Move clients, projects, tasks, time entries and invoices into a tool where records link to each other, whether that is a structured no-code database or an agency management platform. A task should belong to a project, which belongs to a client, so changing one record updates every view.
Automate the data pipeline. Connect ad platforms, analytics and finance tools through native connectors, APIs or automation layers instead of copy-pasting. This is exactly the manual step identified in the JPMorgan model review. Automations still need monitoring, because connectors fail when credentials expire or a platform changes its API.
Apply role-based access. Give people the least access they need, and prefer tools where permissions can be set per record or view rather than relying on file-level sharing.
Define your metrics once. Write down what “Active Client,” “Conversion” and “Retainer Margin” mean, and make every report use the same definitions.
If you stay on spreadsheets for now, add guardrails. Keep inputs and calculations on separate tabs, protect formula ranges, ban typed-over formulas, use a named-version habit before big changes, and have a second person review any figure going to a client. Panko’s research found that people who expect errors, and review in layers, catch more of them.

Conclusion: treat the spreadsheet as a risk, not a record

Shared spreadsheets are not doomed to fail, and they are often the right starting point. But the research on error rates, and costly real-world failures rooted in manual copying and unreviewed formulas, suggest that a spreadsheet should not be your only line of defense once client numbers, billing and team capacity depend on it.

By recognizing version sprawl, formula fragility and thin access controls, you can decide deliberately when to move to structured tools and automated reporting. Doing so won’t guarantee a client stays, but it removes one avoidable reason for them to doubt your numbers.

Is your agency ready to trade fragile spreadsheets for something sturdier? Audit your current client trackers this week: count the copies, find the hardcoded cells, and check who can edit what.

Sources

Panko, R., “Spreadsheet Errors: What We Know. What We Think We Can Do” and “What We Don’t Know About Spreadsheet Errors Today”
Powell et al. field audit summary, via “Error Estimation in Large Spreadsheets using Bayesian Statistics”
JPMorgan Chase Task Force report on 2012 CIO losses, as summarized by James Kwak, Baseline Scenario and ISG
The Register: England’s under-reported COVID-19 cases and Excel’s .xls row limit
Google Help: Protect, hide and edit sheets and Protect a sheet or range
Swydo: Client churn KPIs and why clients leave
Klicks Design: summary of Setup’s 2024 Marketing Relationship Survey
AgencyAnalytics: Marketing reporting guide for 2026

Originally published at https://instarenewal.com/blog/the-single-source-of-truth-fallacy-why-shared-agency-spreadsheets-are-silently

The “Silent Registrar Lockout”: How Agency-Client Miscommunication Breaks Domain Transfers During Offboarding

Memo — Mon, 26 Oct 2026 01:56:41 +0000

Offboarding a digital client should be a clean operational milestone. Deliverables are archived, final invoices are settled, and control of core digital infrastructure (websites, hosting, analytics and primary domain names) is handed back to the client.

One of the most common friction points in these transitions happens quietly, beneath the offboarding workflow. This article calls it the Silent Registrar Lockout.

A Silent Registrar Lockout is not an official industry term. It describes a domain that cannot be moved at the moment an agency or client tries to hand it over. Broken code or missing DNS records are rarely the cause. The usual causes are:

a registrar-imposed transfer lock that nobody knew about
registrar account access held by someone who has left
a contact detail changed at the wrong moment

The result is the same each time: website and email downtime risk, and a strained relationship with a client who is already leaving. This guide explains the mechanisms behind domain locks and gives you a 30-day pre-offboarding checklist to avoid them.

Scope note: ICANN’s Transfer Policy governs generic top-level domains (gTLDs) such as .com, .net and .org. Country-code domains (ccTLDs) such as .uk, .eu or .in follow their own registry rules, so check the relevant registry’s policy before applying anything below to them.

What Causes a “Silent Registrar Lockout”?

A registrar-to-registrar transfer looks simple on paper:

Unlock the domain.
Get the authorization code (also called an Auth code, AuthInfo code or EPP code).
Submit it at the receiving registrar.
Approve any confirmation requests.

In practice, several independent controls sit in the way. Each is sensible on its own, but they collide when an offboarding is rushed.

                 [ Offboarding begins ]
                           │
        ┌──────────────────┼───────────────────┐
        ▼                  ▼                   ▼
 [1. Registrar lock]  [2. Registrant      [3. Registrar account
  clientTransfer-      details changed?     access: who can log in,
  Prohibited?          (name/org/email)     pass MFA, approve emails?]
        │                  │                   │
  Toggle it off     60-day lock applies   Account held by ex-employee
  (or ask registrar unless you opted out  or dead mailbox = stuck
  to do it within   BEFORE the change
  5 calendar days)

Three catalysts account for most lockouts.

1. The Change of Registrant 60-Day Lock

Under ICANN’s Transfer Policy, a “Change of Registrant” is a material change to the registrant’s name, organization or email address. A material change is anything that is not a typographical correction.

When one happens, the registrar must impose a 60-day inter-registrar transfer lock. The only exception is a registrar that offers an opt-out, and the registrant must use it before the change request.

The mistake: Three days before offboarding, an agency “cleans up” the registrant record. It swaps webmaster@agency.com for admin@client.com, intending to help. That is a material change to the email address.
The result: The domain cannot move to another registrar for 60 days, unless the registrar offers an opt-out that was used beforehand. ICANN itself does not place or lift an individual domain’s lock. Some registrars add their own rules for removing the lock, such as extra email confirmation or a waiting period, so ask yours exactly how it handles this.

Two clarifications prevent misdiagnosis:

The lock is imposed by the registrar, not the registry. ICANN’s policy does not require a specific EPP status code for it. If a registrar uses clientTransferProhibited, it must also prevent the customer from removing that status themselves. The lock may therefore be invisible in a public lookup, so ask the registrar for the date it ends.
The policy tells registrars to warn the prior registrant. Anyone who intends to move the domain to a different registrar is advised to request the transfer before the Change of Registrant, to avoid triggering the lock.

2. Orphaned Registrar Accounts and Multi-Factor Authentication

Major registrars and DNS providers such as Cloudflare, GoDaddy, Namecheap and AWS support multi-factor authentication (MFA) on their accounts. That is good security. It becomes a problem when the account’s only administrator no longer works for the agency.

The mistake: The registrar account is tied to a former project manager or developer. It may be tied to a dead alias such as tech-dept-2022@agency.com, or MFA may live on a departed employee’s phone.
The result: On handoff day, nobody can unlock the domain, retrieve the Auth code or approve confirmation emails. Account recovery usually means identity and business verification through the registrar’s support team. How long that takes varies by registrar and can run to days or more.

Note who actually has authority over the transfer. Under ICANN’s policy, the Registered Name Holder is the only party with authority to approve or deny a transfer request. If the client is the registered holder but the agency controls the account, the client has a formal path through the registrar’s support process, but the path is slower than a clean handoff.

3. Registrar Locks: `clientTransferProhibited` and Friends

Registrars set a lock status on domains to prevent unauthorized transfers, and many apply it by default or on request. ICANN’s policy lets a registrar apply clientTransferProhibited only on registration or at the holder’s request, with the terms in the registration agreement.

Two rules matter for offboarding:

A registrar must let the holder remove the lock. If it offers no self-service toggle, it must remove the lock, and provide the Auth code, within five calendar days of the holder’s request.
A registrar generally cannot deny a transfer merely because the domain is locked, unless the holder had a reasonable opportunity to unlock it first.
The mistake: The agency emails the client an Auth code but leaves the domain locked. Or a registry-level hold exists that nobody checked.
The result: The transfer fails or stalls. Because the failure happens between two registrars, neither the agency nor the client sees an error until someone checks the transfer status.

The Technical Anatomy of a Transfer Failure

The Extensible Provisioning Protocol (EPP) defines the status codes registries and registrars use. ICANN’s guidance splits them into two families:

Client status codes are set by registrars.
Server status codes are set by registries and take precedence over client codes.

EPP Status	Set by	What it means	How to resolve it
`ok`	Registry	No pending operations or prohibitions on the record.	A transfer can proceed once you have the Auth code. Also confirm the registrar’s own rules in its dashboard.
`clientTransferProhibited`	Registrar	The registrar lock is on and transfers are rejected.	Turn off the registrar lock in the dashboard. If there is no toggle, ask the registrar to remove it (policy limit: five calendar days).
`clientUpdateProhibited`	Registrar	Updates to the domain object, such as nameservers or contact records, are blocked.	Turn off the update lock before changing nameservers or contacts.
`serverTransferProhibited`	Registry	The registry is blocking transfers.	Needs a conversation with the current registrar. Typical causes include a legal dispute (for example UDRP or a court order) or a paid registry-lock service. Some registries also use it for post-registration or post-transfer locks.

If a transfer is still rejected after you unlock the domain, check for a server-level status first, then for a registrar-imposed Change of Registrant lock. The second one may not appear as a status at all.

Reading the Record Today: RDAP, Not WHOIS

ICANN ended its contractual obligations for gTLD registries and registrars to provide WHOIS (port 43 and web-based WHOIS) on 28 January 2025. The replacement is the Registration Data Access Protocol (RDAP). ICANN provides a lookup at lookup.icann.org.

Two practical points:

An RDAP lookup reliably shows the registrar, registration dates, nameservers and EPP status codes.
Registrant identity, including the registrant email, is typically redacted in public results. You usually cannot audit the registrant email from a public lookup, so check it inside the registrar account instead.

Transfer Mechanics Worth Knowing

These timings come from ICANN’s Transfer Policy:

Five-day default approval. The registry completes a requested transfer unless the current registrar sends a rejection within five calendar days. If the current registrar does nothing, the transfer proceeds. A registrar may deny a transfer only on specific grounds, such as evidence of fraud, a pending UDRP, a court order, or non-payment for a previous registration period on a domain past its expiration date.
Early-life locks. A registrar may deny a transfer within 60 days of initial registration, or within 60 days after a previous inter-registrar transfer.
Term extension. A completed transfer adds one year to the existing registration, up to a maximum total of ten years.

What Is Changing: ICANN’s 2026 Transfer Policy Overhaul

Part of this guide may soon become outdated. The ICANN Board adopted the Transfer Policy Review working group’s 47 recommendations on 7 June 2026. Registrar and industry reporting describes the main changes as:

The Change of Registrant 60-day lock is removed.
The post-registration and post-transfer lock shortens from 60 days to a fixed 30 days.
The Auth code becomes a one-time Transfer Authorization Code (TAC), described by some registrars as valid for 14 days.

None of this is in force yet. As of late October 2026, registrars report that implementation is pending and ICANN has not announced an effective date. The working group recommended an 18-month implementation window, and registrars expect the changes to be phased in. Until ICANN publishes an effective date, plan for the current rules and check ICANN’s Transfer Policy page before relying on the new ones.

The 30-Day Pre-Offboarding Checklist

Start a month before contract end. Discovering a 60-day hold or an access problem in week one still leaves room to work around it. Discovering it on the last day does not.

Stage 1: Assessment and Audit (Day -30 to Day -21)

Identify who holds the registrar account.
- Note where each domain is registered, such as GoDaddy, Namecheap, Cloudflare or AWS.
- Confirm whether the domain sits in an agency master portfolio or a dedicated client account.
Run an RDAP check.
- Look up the domain at lookup.icann.org or another RDAP client.
- Record the registrar, the creation date, the last transfer date, the expiry date and the EPP status codes.
- Confirm the domain is not within 60 days of initial registration or a previous inter-registrar transfer.
Audit registrant details inside the registrar account.
- Check the registrant name, organization and email. These are usually redacted publicly.
- Do not edit them casually. If a change is needed, first ask the registrar whether it offers an opt-out of the Change of Registrant lock, and use it before submitting the change.
- If no opt-out exists, the safest sequence is to transfer first and change registrant details at the receiving registrar afterwards, as ICANN’s policy advises.

Stage 2: Access and Governance (Day -20 to Day -10)

Verify login and MFA.
- Test the registrar login now, not on handoff day.
- Confirm MFA is attached to a shared team vault or a monitored role mailbox, and not to one employee’s personal phone.
Document DNS and plan the nameserver strategy.
- Export all DNS records: A, CNAME, MX, TXT, SPF, DKIM and DMARC.
- Check whether the registrar also hosts DNS. A registrar transfer does not change DNS by itself, but if DNS lives at the old registrar, plan the move separately.
- If DNSSEC is enabled, plan the DS record handling before changing DNS providers.
- Lowering TTLs on critical records to 300 seconds is a common practice before DNS changes, because it speeds up propagation.
Check expiry and billing.
- Make sure the domain is not expired or about to expire, and renew first if needed. Expired domains can run into registrar-specific rules, and non-payment for a prior registration period is one of the policy’s permitted grounds for denial.
- Clear any pending invoices or payment holds on the registrar account.

Stage 3: Handoff Execution (Day -9 to Day -1)

Unlock the domain.
- Switch off the registrar transfer lock in the dashboard.
- Confirm with an RDAP lookup that clientTransferProhibited has gone.
Generate and pass the Auth code securely.
- Generate the code as close to the transfer as possible. Under the pending 2026 rules, codes are expected to be short-lived.
- Send it through a secret-sharing tool or a password manager’s share function, not plain email or chat.
Initiate and monitor the transfer.
- The client, as holder, submits the Auth code at the receiving registrar.
- Watch the registrant email inbox for confirmation requests and approve them promptly.
- Remember that the transfer will complete after five calendar days unless the current registrar rejects it.

Stage 4: Post-Offboarding Verification (Day 0 and After)

Verify, revoke and archive.
- Confirm in an RDAP lookup that the registrar has changed.
- Remove former agency users, API keys and billing profiles from the old account.
- Archive a sign-off document signed by both parties.

Best Practices for Agencies and Clients

For Agencies: Do Not Register Client Domains in Agency Portfolios

The most common root cause of offboarding lockouts is co-mingling. Agencies often register client domains under one agency registrar account because it is quick.

Best practice: Have the client create their own registrar account, and register the domain with the client as the registrant.
Use delegated access to manage it. GoDaddy’s delegate access lets an account owner invite others without sharing passwords, and domain-level permissions can be set through folders. On AWS, use IAM roles in the client’s own account.
Name a role-based, monitored address as the contact, for example domains@clientcompany.com, and not an individual’s email.

For Clients: Own the Registrant Record

The Registered Name Holder is the party ICANN’s policy recognizes as having authority to approve or deny a transfer. If an agency is listed as the registrant, the agency is the registered holder as far as the registrar is concerned.

Best practice: Review your domains at least annually in the registrar account. Make sure the registrant is your organization and the contact email is a monitored, non-personal address you control.

If You Are Already Locked: The DNS Workaround

If a 60-day lock has been triggered shortly before offboarding, you do not have to keep the client waiting or leave the website offline.

The workaround: The 60-day lock restricts inter-registrar transfers. It does not stop the domain from working or prevent the holder from changing nameservers or DNS records.
Leave the domain at the current registrar for the lock period. Point DNS at the client’s new hosting or DNS provider, such as Cloudflare or Route 53, so the site and email move over now.
Ask the registrar for the exact date the lock ends, set a reminder, and complete the registrar transfer once it lapses.

Conclusion: Turn Offboarding Friction into Professional Trust

A lockout is rarely malicious. It usually comes from a few ordinary, avoidable gaps:

a registrant field edited at the wrong time
an account that only one departed person could open
a lock nobody thought to check

Agencies that audit registrar access early, protect the registrant record and start the process 30 days out turn a high-risk handoff into a routine one. Clients that own their registrar accounts and keep their registrant details current remove the problem at the source.

Originally published at https://instarenewal.com/blog/the-silent-registrar-lockout-how-agency-client-miscommunication-breaks-domain

Operational & Workflow Efficiency in 2026: The Ultimate Guide to Modern Business Productivity

Memo — Sun, 25 Oct 2026 04:17:10 +0000

Organizations now have more software, data, and automation options than at any point in business history, yet many employees still feel buried in administrative friction. Asana’s Anatomy of Work research found that knowledge workers spent 58% of their day on “work about work” in its 2023 index, which covers chasing status updates, searching for information, switching between apps, and managing shifting priorities. In earlier editions the figure was 60%. These are self-reported survey results, but the pattern has been consistent for years: more tools have not automatically meant less friction.

Real operational and workflow efficiency is therefore not just about cutting costs or squeezing extra hours out of a workforce. It means designing systems in which people and automation each do what they are best at. The 2026 picture is also more nuanced than the hype suggests. According to McKinsey’s State of AI in 2025 survey (fielded in mid-2025), 88% of organizations use AI in at least one business function, but nearly two-thirds have not begun scaling AI across the enterprise. McKinsey also found that 23% of organizations were scaling an agentic AI system somewhere in the business, with another 39% experimenting, and that no more than 10% reported scaling agents in any single function.

This guide covers the definitions, frameworks, current trends, and practical steps for improving how work actually flows through your organization.

1. Defining the Pillars: Operational vs. Workflow Efficiency

The two terms are often used interchangeably, but they operate at different scales.

+--------------------------------------------------------------------------+
|                       THE EFFICIENCY ECOSYSTEM                           |
|                                                                          |
|  [Operational Efficiency] ---> Macro View: Resources, Costs, ROI         |
|         |                                                                |
|         v                                                                |
|  [Workflow Efficiency]    ---> Micro View: Task Handoffs, Speed, Routing |
+--------------------------------------------------------------------------+

Operational Efficiency (The Macro View)

Operational efficiency measures how well an organization uses its resources (labor, capital, technology, and materials) to produce goods or services. It asks: Are we maximizing output while minimizing waste, overhead, and operating costs?

Workflow Efficiency (The Micro View)

Workflow efficiency focuses on the specific sequence of steps, tasks, data handoffs, and approvals needed to complete one business process. It asks: How smoothly does a customer request, an invoice, or a product change move from start to finish without getting stuck?

Operational efficiency sets the strategic frame, and workflow efficiency is the mechanism that delivers it. If workflows are clogged with manual data entry, redundant approvals, and communication silos, broader operational metrics will suffer.

2. The 2026 Shift: From Static Rules to Agentic Systems

For decades, workflow automation relied on rigid “if-this-then-that” rules. If a form was submitted, an email was sent. If a required field was blank, the process stalled until a person stepped in.

Agentic AI changes the design options, though it is still maturing:

Autonomous AI agents: Unlike a script that executes one fixed instruction, an AI agent is given a goal, breaks it into steps, uses software tools to carry them out, and adjusts when something unexpected happens. McKinsey’s survey defines agents as systems “capable of acting in the real world, planning and executing multiple steps in a workflow.”
Multi-agent collaboration: Rather than isolated bots, some organizations are experimenting with specialized agents working in parallel, for example one handling data intake, another updating the CRM, and a third checking quality. This remains an emerging pattern rather than a settled best practice.
Standardized connectivity (MCP): The Model Context Protocol, introduced by Anthropic, is an open standard for connecting AI models to external tools, data sources, and applications. In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. A shared standard reduces the amount of custom integration work, though connecting agents to legacy systems still takes planning, access controls, and testing.

A Reality Check on the Hype

Analysts urge caution. Gartner predicted in June 2025 that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. It also warned of “agent washing,” where vendors relabel chatbots, assistants, and RPA tools as agentic, and estimated that only about 130 of the thousands of vendors claiming agentic capabilities offer genuine ones. Gartner still expects the technology to grow in importance. It predicts that by 2028, at least 15% of day-to-day work decisions will be made autonomously through agentic AI (up from 0% in 2024), and that 33% of enterprise software applications will include agentic AI.

The takeaway is not to avoid agents but to apply them where there is a clear, measurable payoff. Gartner’s own advice is to pursue agentic AI only where it delivers clear value or ROI and to focus on enterprise-level productivity rather than individual task augmentation. McKinsey likewise found that the small group of high performers is more likely to be redesigning workflows rather than layering AI on top of existing ones.

3. Core Strategies to Transform Operational and Workflow Efficiency

Five strategies help remove friction and scale sustainably.

Strategy 1: Process Mapping and Value Stream Analysis

You cannot optimize what you do not understand, and automating a broken process just makes it fail faster.

Value Stream Mapping (VSM): A lean technique that visualizes every step a request, product, or project passes through from start to delivery, separating value-adding steps from waiting and handoffs.
Identify waste: Lean thinking, which originated in the Toyota Production System, traditionally names seven wastes: transportation, inventory, motion, waiting, overproduction, over-processing, and defects. Many practitioners add an eighth, unused employee talent. In knowledge work, these translate into things like duplicate data entry, approval queues, unnecessary meetings, and rework.
Document and standardize: Once redundant steps are removed, write down the streamlined workflow so everyone works from a single source of truth.

Strategy 2: Hyperautomation for End-to-End Processes

Gartner popularized the term hyperautomation for a business-driven, disciplined approach to identifying and automating as many business and IT processes as possible. In practice, it means combining tools such as RPA, workflow engines, process mining, AI, and system integrations to automate whole chains of work rather than isolated tasks.

Example: Instead of only automating invoice generation, a hyperautomated order-to-cash workflow might capture orders from email, a web portal, or EDI, validate tax details, generate the invoice, match incoming payments to the ledger, and flag exceptions for the finance team to review.

Strategy 3: Shift from Reactive Fixing to Predictive Optimization

Traditional operations react to bottlenecks after they cause delays. Predictive analytics aims to surface them earlier.

Forecasting: Machine learning models trained on historical operational data can forecast seasonal demand, support-ticket surges, or supply delays.
Proactive adjustments: Forecasts can trigger staffing changes, task reassignment, or earlier purchase orders. Gains vary widely by process and data quality, so treat vendor-claimed improvement percentages with caution and measure the effect against your own baseline in a pilot.

Strategy 4: Cross-Functional Collaboration and Distributed Ownership

Efficiency is a cultural discipline, not just an IT or operations project.

Break down silos: When sales, marketing, finance, and support work from separate data, handoffs break. Shared dashboards and integrated systems give everyone the same real-time view.
Enable citizen developers: Low-code and no-code tools let frontline employees build or suggest small automations, since they see workflow friction firsthand. Gartner predicted that by 2026, developers outside formal IT departments would account for at least 80% of the user base for low-code development tools, up from 60% in 2021. This only works with governance: approved platforms, access controls, and IT review for anything touching sensitive data.

Strategy 5: Continuous Improvement with PDCA

Operational excellence is ongoing work. The Plan-Do-Check-Act (PDCA) cycle, long associated with quality pioneers W. Edwards Deming and Walter Shewhart, provides a simple structure:

Plan: Identify an inefficiency and define the expected outcome.
Do: Test the change on a small pilot.
Check: Compare results with baseline KPIs.
Act: Standardize what worked, or adjust and try again.

4. Key Performance Indicators (KPIs) to Track Success

Choose metrics that reflect speed, quality, and cost rather than vanity numbers. Exact definitions vary by organization, so write yours down before you start measuring.

Metric	What It Measures	Why It Matters
Cycle Time	Total time to complete a workflow from start to finish.	Shows speed and where requests stall.
Error & Rework Rate	How often work must be corrected or redone.	High rates point to unclear instructions or bad input data.
Cost per Transaction	Total cost to process one unit of work (such as an invoice or ticket).	Reflects cost efficiency and scalability.
First-Pass Yield (FPY)	Share of items that complete a process correctly the first time, with no rework.	Indicates baseline process quality. A manufacturing term often adapted to knowledge work as a “first-time-right” rate.
Output per Employee	Volume of completed work relative to headcount or hours.	Helps track the effect of reduced administrative burden. Interpret it alongside quality metrics so speed is not rewarded over accuracy.

Pro Tip: Do not track dozens of metrics at once. Pick three to five that map directly to your biggest pain points, capture a baseline before changing anything, and review them regularly.

5. Common Pitfalls in Workflow Optimization

Automating broken processes: Applying automation or AI agents to a poorly understood workflow speeds up the mess. Map and simplify the human process first.
Ignoring change management: New tools fail when people resist them. Explain why changes are happening, train people properly, and gather feedback early.
Creating new data silos: Disconnected point solutions fragment the experience. Favor tools with strong integrations and a shared data layer.
Over-automation without oversight: In high-stakes areas such as compliance, finance, and sensitive customer data, keep human checkpoints. McKinsey’s survey found that 51% of respondents had experienced at least one negative consequence from AI use, with inaccuracy the most commonly reported problem (30%), followed by cybersecurity concerns (10%) and regulatory compliance issues (8%).
Chasing hype: Given Gartner’s warning about agent washing and project cancellations, run small pilots with clear success criteria before committing to large rollouts.

6. Conclusion: Your Next Steps for Operational Excellence

Operational and workflow efficiency supports sustainable growth. Organizations that map their processes, remove unnecessary steps, apply automation where it clearly pays off, and keep humans involved in high-stakes decisions are best placed to cut administrative load and free their teams for higher-value work.

Action Plan for Leaders

Audit your leakage: Identify the two or three processes where you lose the most time, money, or customer goodwill.
Map and simplify: Document those workflows and remove redundant approvals and handoffs.
Pilot smart automation: Introduce targeted automation or agentic tools for repetitive, rule-based tasks, with clear human oversight and a measurable success criterion.
Measure and scale: Compare results with your baseline KPIs, gather team feedback, and iterate.

How is your organization currently tackling workflow bottlenecks or integrating automation into daily operations?

Originally published at https://instarenewal.com/blog/operational-workflow-efficiency-in-2026-the-ultimate-guide-to-modern-business

The “Net 30 vs. Renewal Day” Mismatch: How to Align Client Payment Terms with Hard Expiry Deadlines

Memo — Sat, 24 Oct 2026 01:53:08 +0000

Running a digital, creative, or dev agency carries a quiet financial trap: the gap between client payment terms and third-party renewal deadlines.

Suppose your agency grants a retainer client standard Net 30 terms. On October 1, you invoice $15,000 for retainer work. The invoice also covers a $2,500 annual renewal (a domain portfolio, a certificate subscription, or a software license) that the vendor will charge on October 31. On paper, Net 30 lands the client’s payment on October 31, the same day the vendor needs its money. A bank transfer that is sent on the due date may not clear for several business days. And if the client’s accounts payable (AP) team runs on its own cycle, the money may not arrive until mid-November.

The vendor will not wait for your client’s approval chain. To keep production environments online, agency owners often put the renewal on their own card and wait for the receivable to settle. That quietly turns the agency into an interest-free lender for the client, uses up its credit limit, and exposes it to the risk that the client never pays.

This guide explains why the mismatch happens, which deadlines are truly “hard” and which have a grace window, and how to restructure billing and contracts so your agency stops financing its clients’ infrastructure.

1. Deconstructing the Mismatch

Net 30 is a hope, not a payment date

Net 30 means the invoice is due 30 days after issue. Real payment behavior runs later:

Atradius’s 2025 Payment Practices Barometer for the US surveyed 240 companies. It reported average B2B payment terms of 45 days and found that 43% of B2B invoice value was overdue. Suppliers cited the customer’s own liquidity problems (45%) and delays in the customer’s payment process (33%) as top reasons for late payment.
Intrum’s 2026 European Payment Report found that European B2B suppliers typically give customers 43 days to pay but are paid after about 63 days. That is a 20-day gap, up from 16 days in 2023.
In the EU, the existing Late Payment Directive sets a 30-day default that parties can extend to 60 days or more if the term is not “grossly unfair” to the creditor. A proposal to cap standard B2B terms at 30 days was reported in 2026 as stalled in the Council of the EU.

These are survey averages, and your clients may pay faster or slower. The point is that an invoice due on day 30 can’t be relied on to arrive on day 30.

“Hard expiry” depends on the asset

Not every vendor deadline is a cliff, and not every cliff looks the same. Mapping each asset’s real consequence is the first step in deciding how early you need the client’s money.

Asset	What happens if the renewal isn’t paid on time
Domains (gTLDs such as .com)	Usually a grace window, not an instant loss, but the site and email often stop working. Many registrars park the domain once it expires. Under ICANN’s Expired Registration Recovery Policy (ERRP), the registrant must be allowed to renew after expiry, at least through the period when DNS resolution is interrupted. After deletion, gTLD registries must offer a 30-day Redemption Grace Period, during which DNS resolution is disabled. A short pending-delete period follows, and then the name can be registered by anyone.
Public TLS/SSL certificates	The certificate’s expiry date is the cliff. Browsers warn visitors once a certificate has expired.
Cloud and hosting accounts	Varies by provider. Cloudflare retries a failed renewal five times over five days. After a 5-day grace period it downgrades the account to the Free plan, which does not suspend the website but removes paid features. AWS can suspend an account over unpaid charges. Its support guidance says a suspended account must be reinstated within 30 days, and that reactivation after payment can take up to 24 hours.
SaaS and software licenses	Vendor-specific. Check each vendor’s terms for grace periods and what degrades first.

Domain grace periods also vary by registrar and TLD. For example, Route 53 allows late renewal of a .com until 44 days after expiration, then deletes it from Route 53 on day 45. A registry restoration window runs from day 45 to day 75. Some registries charge a large premium to restore expired domains.

These grace windows are not a reason to pay late. Domains in a redemption or restoration window cost more, and a lapsed name that reaches pending delete can be registered by someone else. Some registrars also charge early. Route 53, for example, auto-renews most domains 35 days before expiration, which is earlier than many agencies assume.

Certificate lifetimes are also shrinking, which makes “annual SSL” billing more nuanced. Under CA/Browser Forum Ballot SC-081v3, the maximum validity of publicly trusted TLS certificates fell from 398 to 200 days on March 15, 2026. It drops to 100 days on March 15, 2027 and to 47 days on March 15, 2029. A certificate vendor’s annual license is often separate from the certificate itself. Billing follows the license term, while the certificate is reissued several times a year.

Why agencies end up floating the cost

When the agency’s own card or reseller account sits behind a client’s renewal, the agency carries the liability. If the client pays late, the agency has two bad options:

Front the capital, using agency cash or credit as an uncompensated bank for the client.
Let the service lapse, risking downtime, lost revenue, and reputational damage that the client may blame on the agency.

2. Key Risks of Floating Infrastructure Costs

A. Working capital depletion

Each fronted renewal ties up agency cash until the client pays. Across many clients, renewals tend to cluster around the same quarter or month, so the exposure can add up quickly.

B. Distorted financial metrics

Pass-through costs affect how your books look. Under US GAAP (ASC 606), whether an agency reports a third-party charge gross or net depends on whether it is acting as a principal or an agent. The test is whether the agency controls the specified good or service before it is transferred to the customer. Indicators include who is primarily responsible for fulfilling the promise and who has latitude to set the price. If the agency is a principal, it records revenue gross and the vendor cost as an expense, which inflates top-line revenue and compresses margin percentages. If it is an agent, it records only its fee. The right treatment depends on your contracts and facts, so confirm it with your accountant. Charging renewals to agency cards also reduces the credit available for payroll, ad spend, and other operating needs.

C. Default and insolvency exposure

If a client disputes an invoice, terminates the contract, or becomes insolvent after you have paid a vendor on its behalf, the agency may be left as an unsecured creditor for amounts it fronted. If the account is in the agency’s name, the vendor looks to the agency for payment.

D. Scope drift and liability creep

Without contractual boundaries, clients come to treat the agency as their payment gateway. When a card fails or an invoice stalls and a service lapses, the agency is often blamed, even if the client never paid.

3. Structural Solutions

+--------------------------------------------------------------------------+
|                    INFRASTRUCTURE BILLING MODELS                         |
+-------------------------------------+------------------------------------+
| 1. Direct Client Ownership          | Client holds the vendor account    |
|    (Preferred)                      | and billing; agency is an admin.   |
+-------------------------------------+------------------------------------+
| 2. Advance Pass-Through Invoicing   | Agency invoices 60 days before     |
|    (the 60/30 rule)                 | expiry; payment due at day -30.    |
+-------------------------------------+------------------------------------+
| 3. Pre-Funded Deposit               | Client keeps a balance the agency  |
|    (Escrow-style reserve)           | draws down for vendor bills.       |
+-------------------------------------+------------------------------------+

Solution A: Client-owned accounts (preferred)

The cleanest fix is to separate infrastructure ownership from agency billing.

Client creates the accounts. The client opens accounts directly with registrars, hosts, and SaaS vendors, using its own payment method and its own organization as the registrant or account owner.
Agency works through delegated access. Use the vendor’s access model rather than shared logins, such as AWS IAM roles, Cloudflare account memberships, or team invitations. Some vendors let you split billing from administration. Cloudflare, for example, has a Billing role that can view invoices and manage payment methods but can’t change subscriptions.
Result. The payment relationship runs between client and vendor. The agency bills for management and engineering under normal terms. Even so, you should still track the renewal dates, because the client’s card can still fail.

Solution B: Advance invoicing (the 60/30 rule)

When clients want the agency to handle billing, invoice third-party renewals on a different schedule from the retainer:

Retainer services: standard terms (for example, Net 30).
Third-party renewals: invoice 60 days before the vendor’s charge date, due in 30 days.

Day -60                       Day -30                       Day 0
   |                             |                             |
   v                             v                             v
Agency issues             Client payment due           Vendor renewal date
renewal invoice           (funds should be cleared)    (agency pays from funds
(Net 30)                                                 already received)

This puts cleared client funds in the agency’s account about 30 days before the vendor needs them, which leaves room for late-paying clients. Adjust the lead time to the vendor. If a registrar charges early, as Route 53 does 35 days before expiry, lengthen the window, for example to 75 or 90 days. If a vendor allows multi-year registrations, you can also invoice for a longer term (many registries allow up to 10 years) and reduce how often you face this deadline.

Solution C: Pre-funded reserve

For consumption-based or unpredictable costs, such as cloud compute, transactional email, or paid APIs, consider an infrastructure deposit held for the client’s third-party spend:

Size the deposit to the exposure, for example two to three months of estimated vendor charges.
Draw from it to pay vendor bills, and invoice monthly to replenish it.
Set a minimum threshold below which the agency pauses optional services or requests a top-up.

Usage-based charges are typically billed in arrears. Cloudflare, for example, bills metered usage after the period closes, so the deposit should cover the bill that is about to arrive, not just the previous month. Have your accountant or attorney confirm how the deposit should be held and recorded in your jurisdiction.

4. Contract Clauses

Your agreement should clearly separate agency service fees, which are earned for labor, from third-party pass-through expenses, which are vendor charges. The sample language below is a starting point only. Have a qualified attorney adapt it to your jurisdiction, because enforceability and liability limits vary.

Clause 1: Advance payment for third-party expenses

Third-Party Expenses. Client acknowledges that third-party services, including domain registrations, web hosting, cloud infrastructure, SSL/TLS certificates, software licenses, and APIs (“Third-Party Expenses”), are billed by their vendors on schedules Agency does not control. Notwithstanding any Net 30 or other credit terms applicable to Agency’s service fees, Client shall pay all Third-Party Expenses invoiced by Agency no later than thirty (30) days before the vendor’s renewal or charge date. Agency is not required to advance funds for Third-Party Expenses.

Clause 2: Notice and right to let a service lapse

Non-Payment of Third-Party Expenses. If Client has not paid a Third-Party Expense by the due date, Agency will send written notice to Client’s designated contacts. If payment is not received at least fifteen (15) days before the vendor’s renewal date, Agency may decline to renew the affected service. To the extent permitted by law, Agency is not liable for service interruption, data loss, or resulting damages arising from non-renewal caused by Client’s failure to pay.

Pair this clause with practical safeguards. If the agency is the registrant or account holder of record, letting a client’s domain lapse is far riskier than if the client holds the registration, because the client can still argue the agency was responsible for it. Document every notice. Remember also that a lapsed domain can eventually be picked up by someone else, so the “right to lapse” is a last resort, not a plan.

Clause 3: Handling fee

Handling Fee. Where Agency, at Client’s request, pays or administers Third-Party Expenses on Client’s behalf, Client shall pay a non-refundable handling fee of [__]% of the vendor’s charge.

Set the percentage to reflect your real administrative cost and market norms for your clients. Whether this fee is a service fee, and how it affects gross-versus-net reporting, is a question for your accountant.

5. Standard Operating Procedure for Renewal Billing

              THIRD-PARTY RENEWAL BILLING WORKFLOW

T-60   Issue a dedicated pass-through invoice, due at T-30.
T-45   Friendly reminder to the client's AP contact and account owner.
T-30   Invoice due. Confirm funds received (not just "payment sent").
T-20   Past-due notice to the AP team and the account owner.
T-15   Final written warning that the service will not be renewed
       by the agency if payment is not received.
T-10   Escalate to an executive stakeholder at the client.
T-0    Paid:   renew from received funds.
       Unpaid: follow the contract. Do not renew, and keep records.

Maintain a master expiry ledger

Track every domain, host, certificate, and license across all clients in one place. A spreadsheet, a database, or your PSA or accounting software all work. For each asset, record:

Client name and primary billing contact
Asset type (domain, hosting, SSL, API, license)
Vendor, account owner, and who holds the payment method
Renewal date and the vendor’s own auto-renew timing
Invoice date, invoice status, and payment status

Keep pass-through invoices separate

Don’t combine monthly retainers and annual renewals on the same invoice. A single invoice inherits one due date, and a late retainer approval then delays the renewal money. Issue pass-through renewals as separate invoices with their own earlier due dates.

Verify who actually receives vendor notices

Vendor expiry warnings go to whatever email is on the account. If the account sits with a former employee or a personal mailbox, the warning may never reach anyone who can act on it. Route renewal notices to a shared agency alias, and also to the client’s billing contact where the client owns the account.

Comparison: Billing Models at a Glance

Model	Main advantage	Agency financial exposure	Best for
Client-owned accounts	The client pays the vendor directly	Lowest	Core hosting, cloud accounts, SaaS subscriptions
60-day advance pass-through	Works with client AP cycles and protects cash flow	Low	Domain renewals, certificate subscriptions, dedicated hosting
Pre-funded deposit	Keeps services running without the agency lending	Low, if the deposit covers the exposure	Metered compute, email, and API usage
Renewals bundled into a Net 30 retainer invoice	One invoice per client	High	Not recommended for expiry-critical renewals

Summary Checklist for Agency Leadership

Audit existing agreements. Review your MSAs and SOWs for a clear split between agency fees and pass-through costs.
Map each asset’s real deadline. Note which services have grace windows and which stop immediately, using each vendor’s documentation.
Shift ownership where you can. Move billing and account ownership to the client wherever feasible, and keep administrative access through delegated roles.
Re-time your invoices. Invoice renewals at least 60 days ahead, and longer for vendors that charge early.
Write notice and non-renewal terms into contracts. Have counsel review them.
Track dates centrally. Keep a single ledger of renewal dates, account owners, and who pays.

Sources and Further Reading

Originally published at https://instarenewal.com/blog/the-net-30-vs-renewal-day-mismatch-how-to-align-client-payment-terms-with-hard

DEV Community: Memo

The “Who Logs In?” Audit: Untangling Super-Admin Rights vs. Billing Contact Rights on Client Software

1. Why Super-Admin and Billing Rights Get Confused

How major platforms actually draw the line

The two classic onboarding mistakes

2. How the Blame Lands on the Agency

Scenario A: The ghost inbox

Scenario B: The administrator who can’t see the bill

3. Step-by-Step: Running the “Who Logs In?” Audit

Stage 1: Map the software inventory

Stage 2: Audit roles and permitted actions

Stage 3: Decouple and delegate

Stage 4: Document and formalize

4. Contractual and Operational Protection

Put ownership and payment responsibility in the agreement

Define an emergency escalation protocol

5. Checklist: The “Who Logs In?” Framework for Onboarding

Conclusion: Turning Governance into a Value-Add

The “I Didn’t Authorize That” Dispute: How to Pre-Clear Renewal Invoices Without Killing Momentum

1. The Real Cost of Renewal Friction

What it costs

2. Why Clients File “Unauthorized” Disputes (It’s Not Always Malice)

3. Designing Pre-Clearance Checkpoints in Onboarding Documents

Essential clauses for your Master Services Agreement

A. Express recurring billing authorization

B. Clear non-renewal window rules

C. A billing-question escalation path

4. The Renewal Pre-Clearance Workflow

Stage 1: The renewal notice (30 or more days out)

Pre-renewal notification email template

Stage 2: Account management alignment (14 or more days out)

Stage 3: Charge day, with a recognizable descriptor

5. Regulatory and Network Rules: What Applies to B2B

6. Card Disputes vs. ACH Returns

7. Structuring Onboarding to Secure Pre-Authorization

1. A dedicated billing consent checkbox

2. Tokenized payment capture and card updates

3. The kickoff call

8. What to Do When a Dispute Arrives

Step 1: Reach out directly (within 24 hours)

Re-engagement email template

Step 2: Respond with evidence before the deadline

Summary Checklist: Building a Frictionless Renewal Engine

Sources and Further Reading

The “Who Holds the Keys?” Audit: Mapping Registrar Account Ownership vs. Agency Operational Access

Technical Admin Rights vs. Account Ownership

Contact Roles: What Still Exists

The Core Conflict: Agency Master Account vs. Client-Owned Account

Anatomy of a Domain Custody Battle

1. The Convenience Trap During Onboarding

2. The Personal Employee Registration

3. The Reseller Trap

The “Who Holds the Keys?” Audit: Five Steps

Step 1: Check Registration Data (RDAP)

Step 2: Map the Registrar Account

Step 3: Audit MFA and Recovery Channels

Step 4: Audit Nameserver and DNS Control

Step 5: Review Contract Alignment

Access Matrix: Who Can Do What

Best Practices: Agency Access Without Sacrificing Ownership

1. Put the Domain in a Client-Owned Account

2. Use Native Delegation Tools

3. Apply Transfer Locks and Consider Registry Lock

4. Write Offboarding Into the MSA

Emergency Remediation: Recovering a Trapped Domain

Executive Audit Checklist

Securing Your Digital Footprint

The “Net-Zero Retainer” Fallacy: Why Bundling Renewal Costs into Fixed-Fee Contracts Destroys Agency Margins

The Anatomy of the Net-Zero Retainer

What Vendors Have Actually Done Recently

1. Domain Registry Increases: The Quiet Compounder

Case Study: The .com Price Ladder

Other Extensions Move Too

2. SaaS and Software License Tier Creep

The Client Growth Paradox

The Operational Risk of Holding Client Assets

How to Unbundle Renewal Costs Cleanly

Step 1: Establish Clear Contract Boundaries

Step 2: Move Billing to Client-Owned Accounts Where Possible

Step 3: Move to Pass-Through Plus a Management Fee

Case Study: The `.com` Price Ladder