The decision this protects
Whether an account is cleared to carry the planned budget on the planned date. The output is a go or a dated list of what blocks the go, made before creative is finalised, because a verification queue discovered in launch week becomes the campaign’s schedule.
Before you start
- Admin access to the client’s Business Manager or Business Portfolio, not just the ad account.
- Admin access to the Google Ads account and its payments profile.
- The business’s registration documents: GST certificate or certificate of incorporation for India, and the registered legal name exactly as written.
- The planned daily budget and launch date, so “cleared” has a number and a deadline to be cleared for.
Stated limits
- Neither platform publishes its thresholds. This sheet clears the signals you control; it cannot promise a specific ceiling, and [VERIFY] marks every place a number would otherwise be guessed.
- Interface paths move. Where to check is described by section name; expect to search the platform’s help for the current click path.
- Policy problems (rejected ads, restricted verticals) overlap with trust but have their own machinery; this sheet flags them and does not resolve them.
1. Meta: identity
| Field | What to record | Why it matters |
|---|---|---|
| Business Verification status | Verified, pending, not started, from Security Centre | The single largest trust item; the one that lifted the cap in the incident behind this sheet |
| Legal name match | Registered name vs the name on the payment method vs the verified name | A mismatch between who is verified and who pays is a trust signal in the wrong direction |
| Domain verification | Domains verified in Business settings | Ties the ads to a web identity |
| Two-factor on all admins | Enforced or not | Compromised-admin risk is priced into account trust |
Judgment prompt: Is the entity being verified the same entity that signs the ad invoices, and if not, whose account should this campaign actually run from?
2. Meta: history
| Field | What to record | Why it matters |
|---|---|---|
| Account age | Months since first spend | Young accounts carry ceilings that only history removes |
| Spend history | Steady, spiky, dormant then sudden | Sudden scale on a quiet account is the pattern limits exist for |
| Payment method | Type, age, past failures from the Billing page | Failed charges reset trust |
| Policy record | Rejected ads count, past restrictions | Each strike lowers the ceiling headroom |
| Admin roster | How many people, how many agencies, any unknown | An account passed between agencies accumulates strangers with admin rights |
Judgment prompt: If the plan needs spend the account’s history does not support, does the timeline move, or does the budget ramp in steps that build the history first?
3. Google: identity
| Field | What to record | Why it matters |
|---|---|---|
| Advertiser verification status | Complete, in progress, not started | Google’s equivalent programme; incomplete verification can pause serving entirely [VERIFY: current enforcement stage for India] |
| Payments profile name | Exact match to the registered business name | The mismatch that “circumventing systems” suspensions often trace back to |
| Payments profile country and currency | Match to the business’s registration | Changed later only by making a new profile, which resets billing history |
| Manager account structure | Which MCC has access, and who owns admin | Ownership disputes freeze accounts at the worst time |
Judgment prompt: Does the name on the payments profile match the GST certificate character for character, including Pvt Ltd vs Private Limited?
4. Google: history
| Field | What to record | Why it matters |
|---|---|---|
| Billing history | Months of clean payments | New accounts carry early spend ceilings that rise with history [VERIFY: no published figure; record observed behaviour instead] |
| Policy strikes | From the policy manager | Same logic as Meta’s record |
| Conversion tracking ownership | Whose tag, whose account | Trust items include whether the account’s data is its own |
Judgment prompt: Is there an older, cleaner account this business already owns that should carry the campaign instead of a fresh one?
5. The clearing plan
| Field | What to record | Why it matters |
|---|---|---|
| Item not clear | From the sections above | The work list |
| Action | Start verification, fix the profile name, enforce 2FA, remove stale admins | One concrete verb each |
| Owner | A name | Verification stalls when it belongs to everyone |
| Date needed by | Working back from launch | Queues take days to weeks [VERIFY: your own observed durations]; the date says when waiting becomes escalating |
| Status | Open, submitted, cleared | Reviewed weekly until launch |
Judgment prompt: Which single item, if it stalls, moves the launch date, and has the client been told that today?
The defensible output
One line per platform: “Meta cleared for launch on [date]: verification complete, names match, 2FA enforced, no policy strikes” or “Not cleared: [item], owned by [name], due [date], launch moves if it slips.” Signed by whoever owns the launch, so the day a ceiling appears mid-campaign, the record shows what was cleared and what was knowingly risked.
Where I could be wrong
The checklist treats verification as the dominant lever because that is what the incident behind it showed, on one account, once. Platforms weigh signals this sheet cannot see, and an account can clear every item here and still hit a ceiling, particularly in categories the platforms consider risky.
It also assumes the budget is the variable and trust is the constraint. For most small advertisers the reverse holds, and this sheet is overhead; it earns its keep at the point where a single day’s throttled delivery costs more than the hour the sheet takes.
Sources
- Meta Business Help Centre, About business verification
- Meta Business Help Centre, About daily spending limits
- Google Ads Help, About advertiser verification
- Google Ads Help, Circumventing systems policy
- Google payments profile documentation