How to Set Up a Microsoft Ads Account Audit

Set up a Microsoft Ads account audit by defining the business question, account boundary, owner, access, currency, time zone, campaign inventory, conversion source of truth, change history, and proof condition before interpreting performance. The audit is a controlled evidence-gathering workflow: it should show what is configured, what the business expects, what the reports prove, and what remains unknown. Saving a setting or exporting a report is not itself a successful audit.

Start with the account, manager relationship, business or legal entity, domain, markets, currencies, campaigns, products or services, landing pages, phone and form routes, UET, conversion goals, budgets, bids, imports, negatives, and relevant downstream records. Microsoft's account-organization guidance, currency guidance, time-zone guidance, and conversion-tracking documentation provide the platform foundation. This article is educational advertising guidance, not account administration, legal, financial, privacy, or platform-policy advice; the account owner remains responsible for decisions and approvals.

What should a Microsoft Ads account-audit setup produce?

The setup should produce a reproducible audit brief and a safe evidence boundary. Before opening a report, write the question the audit must answer, such as whether the account can measure accepted orders, whether a service campaign reaches its approved market, whether an import changed campaign intent, or whether a tracking defect explains a reporting difference. Do not begin with an invented benchmark or a list of settings someone calls “best.”

Write the contract and acceptance criteria

State the requested outcome in one sentence and list the smallest observations that would prove it. A campaign-readiness audit might require verified account identity, accurate currency and time zone, known access owners, tested UET goals, mapped campaigns, reconciled conversion records, and documented blockers. A narrow audit may require fewer criteria. Keep the scope proportional to the decision.

Define what is outside scope: campaign edits, new creative, bid changes, privacy approval, legal review, product or service quality, CRM remediation, or deployment. If another owner must decide an issue, record it as an open decision rather than silently changing the account.

Choose the evidence period and comparison boundary

Record the account time zone, reporting dates, currency, market, campaign types, device or network scope where relevant, and the event or order lag that matters to the business. Use one consistent boundary for the comparison and note any reason a second period is necessary. A report that mixes account time zones, currencies, campaign surfaces, or pre- and post-change data can create a false finding.

Preserve the before-state: account settings, users, campaign settings, goals, UET, imports, negatives, search terms, landing pages, feed or product data, and downstream records needed to prove the question. Use approved exports or references, not untracked screenshots scattered across personal storage.

Assign owners before collecting data

Name the account owner, audit lead, tracking owner, website or feed owner, CRM or order owner, finance owner, privacy or compliance reviewer, and change approver. For each evidence item, record its source, capture date, owner, retention location, and proof condition. The audit should not grant broader access or copy sensitive customer data merely to make reconciliation easier.

How should you confirm the Microsoft Ads account boundary?

Confirm that the audit is in the intended account before interpreting any campaign metric. Microsoft account settings can shape reporting, billing, access, and campaign behavior. The Microsoft Ads account-audit settings guide is related reading, but this setup page focuses on preparing the audit and preserving evidence.

Identify the account, manager, entity, and domain

Capture the account name and number, manager relationship, business or billing entity, website or app, market, payment owner, primary contact, and account status. Check whether the account is a production, test, former, duplicate, agency, brand, or regional account. If several accounts use similar names or domains, document why the selected account is the correct target.

Do not rely on a campaign label or browser tab to identify the account. A complete report from the wrong client, store, branch, or currency is still an audit failure.

Verify currency and time zone before reports

Record account currency and time zone before reading cost, budget, schedule, or daily-performance fields. Microsoft says account currency affects billing and cannot be changed after setup; its time zone controls account and campaign timing and can affect reporting and daily spend patterns. Treat those as scope facts to verify, not as settings to change casually to make a report look familiar.

If the business operates across markets or currencies, define the approved conversion or normalization method outside the platform report. Do not compare raw amounts from different currencies or time zones without documenting the transformation and owner.

Confirm access and approval ownership

Inventory users, manager access, roles, payment access, API or script access, feed or import ownership, and change-history visibility. Identify who may view sensitive evidence, who may approve an account edit, and who may deploy a website or tracking change. Remove or escalate access that cannot be explained by a current owner; do not change permissions during an audit without approval and a rollback record.

How should you inventory campaigns and account structure?

Build the inventory before judging performance. The goal is to connect each campaign to a real business decision and a receiving route, not to make every campaign use the same name or shape.

Map campaigns to business routes

For each account entity, record campaign type, campaign name and ID, status, market, language, product or service, audience, network, schedule, budget, bid strategy, ad groups or asset groups, keywords or product groups, ads and assets, landing pages, phone and form routes, conversion goals, import source, and owner. Add the approved business outcome the campaign is expected to influence.

A useful map separates brand, generic, product, category, service, location, remarketing, Shopping, Performance Max, lead, call, and experimental routes when those distinctions change a decision. Do not infer intent from a name alone. Read the keywords, products, locations, assets, page, and conversion goal together.

Record status and change history

Capture enabled, paused, removed, draft, disapproved, limited, or other observed statuses and the date each was recorded. Review Microsoft Advertising change history or the relevant account record for edits to budgets, bids, targeting, ads, goals, imports, negatives, and schedules. The platform report is evidence of a change, not proof that the change improved business results.

Keep a before-state for material changes. Record change owner, reason, expected effect, proof condition, rollback condition, and any dependency on a feed, app, website, CRM, phone system, or future import. Do not overwrite the prior state with a new export that removes the comparison.

Separate account, campaign, ad-group, and product responsibilities

Identify which decisions belong at account level, campaign level, ad-group or asset-group level, product-group level, feed level, website level, and order or CRM level. A campaign-level budget cannot correct a wrong product price; an ad-group negative cannot repair a missing UET event; a UET goal cannot make an unavailable service or product eligible.

Record shared budgets, shared negative lists, shared audiences, portfolio bid strategies, feed rules, recurring imports, and cross-campaign exclusions. Shared controls can be the cause of a multi-route finding, so show their consumers before recommending a change.

How should you set up the measurement part of the audit?

Set up measurement as a chain from ad interaction to an authoritative business record. Microsoft's UET setup documentation, conversion-tracking explanation, and campaign-level conversion guidance describe platform concepts. The business owner defines what counts as a meaningful event.

Inventory UET tags and goals

Record the UET tag or tags, site or app routes, goals, event rules, custom events, page-view dependencies, consent behavior, goal status, counting behavior, conversion window, attribution setting as observed, value and currency, campaign association, and owner. Identify where each event should fire and which source system proves it occurred.

Do not treat a tag loading as proof of a conversion. A valid setup needs a tested trigger, deduplication behavior, downstream record, and explanation of what the event means. If several tags, analytics tools, apps, phone integrations, or offline imports can create the same event, record each path.

Define the source of truth for each stage

Map platform events to the business system that owns the stage:

click and landing-page behavior to the advertising report and site evidence;
form or call receipt to the approved form or phone system;
appointment, booking, lead qualification, or consultation to the CRM or scheduling system;
accepted order, payment, fulfillment, subscription, refund, or return to the store or finance system; and
revenue, cost, margin, or contribution to the approved finance record.

Do not let a platform conversion label replace the source record. Keep page view, click, form submit, connected call, qualified lead, appointment, order, fulfilled outcome, and value separate when they answer different questions.

Plan safe test cases

Write the tests before running them: valid action, invalid form, validation error, confirmation reload, duplicate submission, missed call, staff test, cancelled action, failed payment, refund, return, or another edge case relevant to the account. Define expected platform event, expected source-system record, expected value, and expected non-event for each.

Use the account's approved test identities and environments. Do not send real customer data, confidential notes, payment data, or unnecessary personal information into advertising events or shared audit files. If a test cannot be run safely, record the unproven claim and the owner who must approve an alternative.

Which reports and evidence should you collect first?

Collect the smallest evidence set that can prove the audit contract. More exports are not automatically a better audit; each one should settle a defined claim or expose a required comparison.

Capture account and campaign configuration

Record account settings, users and roles, billing or payment readiness, campaigns, ad groups, keywords, product groups, ads, assets, locations, languages, schedules, networks, budgets, bids, audiences, conversion goals, UET, imports, negatives, feeds, final URLs, and status. Capture the date and time zone with every export.

Use Microsoft's report-field documentation to identify the fields relevant to the question. Keep configuration evidence separate from performance evidence; a current setting does not prove what happened during an earlier period.

Collect search-term, product, call, and landing-page evidence

For Search, review search terms with keyword, match type, campaign, ad group, market, device or network where relevant, page, conversion, and approved outcome. For Shopping or feed campaigns, review item or variant, product group, title, price, availability, link, diagnostics, and order route. For calls and forms, record receipt, response, qualification, duplication, and source-system reference. For pages, capture the exact version, route, offer, form, call link, and confirmation behavior.

Classify intent before proposing a negative. A word may represent an eligible product, service, support path, market, or customer question. Use the Microsoft Ads negative-keyword settings guide for related review, but keep the account's actual query evidence as the basis for an action.

Reconcile to downstream records

Join platform evidence to the approved source of truth using stable internal or transaction references where appropriate. Compare counts and values by the same campaign, market, product or service, date, and stage. Explain mismatches instead of forcing the systems to agree: time zones, attribution windows, duplicate events, offline actions, manual entries, delayed updates, failed handoffs, consent choices, refunds, returns, or untracked calls can all matter.

Do not copy full customer, patient, legal, financial, property, payment, or order narratives into a general audit workbook. Store sensitive detail in the system that owns it and record only an approved reference, aggregate category, or finding needed to prove the contract.

How should you handle imports and shared controls during setup?

Imports and shared controls can change several routes at once. Treat them as dependencies that need owners and proof, not as convenient shortcuts.

Record import scope and schedule

Microsoft's campaign import workflow and import field guidance explain the platform process. Record source account, destination account, entities selected, currency and time zone, campaigns, budgets, bids, keywords, match types, negatives, ads, assets, locations, audiences, URLs, conversion goals, tracking, product data, and recurring schedule.

Identify which settings are translated, unsupported, overwritten, paused, or recreated. Compare source and destination behavior after import. A successful import or recurring schedule is not proof that the destination campaign has the same meaning, scope, tracking, or business outcome.

Map shared controls to their consumers

List shared budgets, negative lists, audiences, portfolio bid strategies, feed rules, conversion goals, tags, app integrations, and recurring imports. For each, record every campaign or route that consumes it, the owner, rationale, last review, expected behavior, and proof condition. A shared control with an unclear consumer is an audit finding even if no current performance anomaly is visible.

Do not edit a shared control while setting up the audit unless the user has separately authorized that change. Preserve the current state, report the risk, and obtain the owner decision.

How should you record findings and validation?

Use a report that makes the evidence and decision boundary visible. The Microsoft Ads account-audit settings guide provides related categories; this setup workflow should leave the account owner with a usable issue register and proof plan.

Use a finding record with a proof condition

For each finding, record:

account, campaign, route, market, product or service, and period;
observed behavior and expected behavior;
evidence source, capture time, owner, and confidence or limitation;
impact on tracking, delivery, cost, customer route, order, lead, or business outcome;
correction, decision, controlled test, or rejected claim;
owner, approval needed, proof condition, and rollback condition; and
validation result and date after the action.

Keep findings separate from fixes. A finding is not closed because someone proposes a change, and a fix is not proven because a setting saved successfully.

Prioritize by contract impact

Start with issues that make the requested outcome unmeasurable, misroute the intended audience, expose sensitive information, create an incorrect business value, or cause a material delivery or source-data failure within the defined scope. Do not invent a score, threshold, deadline, or severity scale unless the account owner or project policy requires it.

Reject claims that do not break the audit contract in one line: “No action: the available evidence does not show that this issue makes the requested audit outcome unmet or unproven.” Useful future ideas can be recorded separately only if the owner asks for them; they are not part of the current proof.

Re-test only the changed claim

After an approved correction, recheck the exact account, campaign, event, page, product, call, form, import, or source record that the correction was meant to change. Preserve before and after evidence. If the proof condition fails, leave the finding open and state the exact blocker. Do not expand the audit merely because another possible improvement appears.

Microsoft Ads account-audit setup checklist

Before entering reports

Define the requested outcome, smallest acceptance criteria, out-of-scope actions, owner, approver, period, currency, time zone, markets, and source-of-truth systems.
Confirm account name and number, manager relationship, entity, domain, production or test status, users, roles, billing owner, and change-history access.
Preserve account, campaign, UET, conversion, import, negative, feed, landing-page, and downstream before-state evidence.

During setup

Inventory campaigns, ad groups, keywords, product or listing groups, ads, assets, locations, languages, schedules, budgets, bids, audiences, goals, imports, shared controls, and final URLs.
Map every important event to its authoritative form, call, CRM, order, fulfillment, subscription, return, or finance record.
Plan valid, invalid, duplicate, cancelled, failed, refund, return, and staff-test cases that match the account's actual routes.
Record source, timestamp, owner, access boundary, expected behavior, and proof condition for each evidence item.
Keep personal, confidential, payment, property, legal, medical, and customer details out of general audit files.

At the conclusion

Classify every material result as defect, decision, hypothesis, limitation, proven result, or rejected claim.
Assign owner, approval, correction or test, proof condition, rollback condition, and validation date.
Re-test changed claims and preserve before-and-after evidence.
Report unresolved blockers and unproven claims without silently editing the account or deploying a website change.

The bottom line on setting up a Microsoft Ads account audit

A reliable Microsoft Ads account-audit setup starts with a clear question and ends with evidence that can prove or reject it. Confirm the account boundary, currency, time zone, access, and owners first. Then map campaigns and shared controls, inventory UET and source systems, preserve the before-state, collect only necessary reports, reconcile downstream outcomes, and document proof conditions before any change is approved.

Do not call the audit ready because a report downloaded, a UET tag loaded, an import completed, or a campaign is enabled. Readiness means the account, scope, evidence, source of truth, owner, and validation path are known. adz.so provides educational advertising guidance and does not administer accounts, approve legal or privacy decisions, guarantee tracking, change campaigns, or promise performance.

Sources and related reading

The platform details and links above were checked against Microsoft Advertising documentation on 2026-08-15. Interfaces, account eligibility, access controls, conversion behavior, import behavior, privacy expectations, and reporting fields can change; verify the live account, approved source systems, and current official documentation before applying a finding.