Treat the register as a working record
A purchased advertising account is both a product and a working tool. A simple spreadsheet can help a team track what it received, what was agreed with the seller, who is responsible for it, and what happened when it stopped being used. The register is not a substitute for checking an account or following a platform’s terms. It is a shared record that makes those tasks easier to manage.
Use one row for each account. Keep the fields consistent so team members can compare entries and spot missing information. If the spreadsheet becomes crowded, add separate tabs for supporting documents or notes, but keep the main row readable. A short entry with a link to a relevant document is often more useful than a long description that is difficult to maintain.
Limit access to people who need the register for their work. It can contain sensitive business information even when it contains no login credentials. Agree on who updates it and when, such as when an account is received, responsibility changes, a claim is opened, or the account is retired. A register is useful only if the team can rely on its entries.
Identify the platform and account type
Start with the platform and the type of account. For example, identify whether the entry relates to Meta Ads, Google Ads, TikTok Ads, or LinkedIn Campaign Manager, then describe the account type in plain language. This may be an advertising account, a business account, or another relevant platform product. Use the platform’s own terminology where it is clear, and avoid vague labels such as “old account” or “main login.”
Add a brief note about the intended job: for example, which team, client, or approved campaign workflow the account is meant to support. This helps distinguish accounts that might otherwise look similar. It also gives the team a reason to reconsider whether an account is suitable when the work changes.
Do not use the register to document ways to evade platform checks, disguise ownership, or work around restrictions. Record the account as it is represented and used within the platform’s terms. If the account’s status or eligibility is unclear, flag that uncertainty and resolve it through appropriate platform or seller channels before relying on the account.
Record the source and receipt details
Record where the account came from: the seller or supplier name, the relevant marketplace or referral channel if applicable, and the contact route used for the transaction. Include the date received, using a format the team can interpret consistently. The date helps establish when the account entered the team’s custody and provides context for later handoffs or warranty discussions.
Note how delivery was completed without putting access secrets in the spreadsheet. For instance, record that access was transferred through an approved handover process, and link to a restricted document if the team needs a fuller audit trail. Do not paste login details, mailbox passwords, recovery codes, phone verification details, or session information into a cell.
If the source or delivery details cannot be verified, say so rather than filling the gap with an assumption. A clear “not confirmed” note is more useful than a confident-looking entry that could mislead the next person. Keep any supporting receipts or written correspondence in a secure, organized location, and link to them only if the intended readers have appropriate access.
List owners, admins, and the operator
Record who the listed owners and administrators are, using names or team roles that the team can recognize. Distinguish between the person or entity shown as the owner and those who have administrative access. These roles may not be the same, and the difference can matter when access needs to be reviewed or a business relationship changes.
Add the team member responsible for operating the account. This is the person who handles routine work, not necessarily the owner or administrator. If responsibility changes, update the register promptly and retain a note of the handoff where useful. Avoid leaving an account assigned to someone who no longer works on it.
The register should not become a workaround for platform access controls. Use the platform’s available role and permission features, and keep the recorded list aligned with authorized access. If the listed ownership or administration does not match what the team understands was agreed, flag the discrepancy and clarify it before treating the account as ready for use.
Capture what was promised in writing
Use a field for the seller’s written commitments. Summarize them in neutral, specific language: what was represented about the account, what was included in the handover, and what support or remedy was described if a stated condition was not met. Do not turn informal expectations into promises. If something was discussed only verbally, mark it as verbal or unconfirmed rather than presenting it as a written term.
Link to the relevant written record, such as an invoice, order confirmation, agreement, or message thread, stored in a location with suitable access controls. The spreadsheet summary should help a teammate find and understand the record; it should not replace the underlying document. Keep the wording factual and separate the seller’s statement from the team’s own assessment.
Record the warranty window as written, including its start point and any conditions that are explicitly stated. If no warranty was offered, or the terms are unclear, say that. Avoid assuming that a general promise covers every issue or that a window begins on a particular event unless the written terms say so. This makes later discussions more grounded and helps the team evaluate the purchase process.
Track claim status and follow-up
Give warranty or support claims their own status field. Use plain labels such as not opened, under review, resolved, or disputed, and add a short note on the issue and the next action. Include the person responsible for follow-up and a link to the related correspondence when appropriate. This prevents a claim from disappearing into an inbox or being mistaken for a settled matter.
Keep the status current as the conversation develops. Record the outcome without editorializing: for example, whether the seller responded, what resolution was agreed, or whether the matter remains unresolved. If the platform itself has an account-status issue, record that separately from a seller claim. The two may be related, but they are not the same process.
Use the register to support decisions, not to imply that a claim will succeed. A clear chronology and a link to the written terms can help the team understand what was agreed and what remains to be done. If the situation requires platform support or professional advice, use the appropriate channel rather than relying on a spreadsheet entry as a determination.
Keep credentials in a password manager
Never put passwords, authentication tokens, recovery codes, private keys, or mailbox credentials in the purchase register. A spreadsheet is designed to organize information, not to serve as a secure credential vault. Even a restricted file can be copied, shared, or retained in places the team does not expect.
Store credentials in a proper password manager with access controls suited to the team. Record only a neutral reference in the register, such as the name of the vault item or a secure internal identifier, if that helps authorized teammates locate it. Do not include the secret itself, and do not expose it through a spreadsheet link or comment.
Mailbox and phone access may be part of an account handover, but those details deserve careful handling too. The register can note that a recovery method was reviewed or transferred, without recording the address’s password, phone credentials, or codes. Keep the account’s recovery arrangements under the control of authorized people and follow the platform’s permitted procedures.
Retire accounts with a clear reason
When an account is no longer used, record when it was retired and why. Use a concise, factual reason, such as a change in the team’s needs, an unresolved access issue, a seller-term dispute, or a decision to stop using that account type. Do not erase the row; mark it retired so the team can distinguish inactive records from active tools.
The reason matters for the next purchase decision. If several entries show that a particular handover detail was repeatedly unclear, the team can make that detail a required written term in future transactions. If an account was retired because it did not fit the intended workflow, the team can refine how it evaluates account type and platform fit. A record of what did not work is a practical input to better questions and more careful acceptance checks.
Review the register periodically for missing owners, outdated operators, open claims, and accounts whose status is uncertain. Keep the process simple enough that the team will maintain it. A dependable register will not guarantee a smooth purchase, but it can make responsibilities, terms, and past decisions easier to see before the next one is made.