Access Is Not Ownership: Three Ledgers for Digital Business Profiles

Digital business systems reuse the word owner for several different ideas. A person may be an owner of a local profile, a super administrator of a company page, the owner of a domain account, or the legal owner of a company or property. Those roles can overlap. They do not have to.

The operational mistake is to let a platform permission become a business relationship claim. An account screen can show who is allowed to edit a record. It does not, by itself, establish the entity that owns the brand, operates the facility, employs the administrator, licenses the mark, or provides a product. The same separation protects against the opposite mistake: a legal relationship does not automatically prove that the right person currently has access to the exact profile.

Platforms define permissions, not the whole business

Google Business Profile distinguishes owners and managers by what they can do to a profile. Owners can manage users and remove a profile; managers can perform most day-to-day profile work but cannot add or remove users or remove the profile. LinkedIn likewise defines Page roles by permissions: a super admin can manage admins and edit Page fields, while content admins and analysts receive narrower capabilities.

Those are meaningful controls inside each platform. They should be recorded precisely. But the safest reading is narrow: the role describes authority over that platform record. If a public biography, structured-data graph, media kit, contract summary, or facility directory needs a legal or operating relationship, it needs a source that governs that separate fact.

The three-ledger model

1. Public fact ledger. Record the exact customer-facing name, address, phone, hours, category, canonical URL, lifecycle state, and approved description. Each field needs a governing source, reviewer, effective date, and last-visible verification.
2. Platform access ledger. Record the platform, exact profile or property URL, role vocabulary, current administrator state, verification status, recovery owner, last access review, and any pending invitation or transfer. Keep personal account identifiers restricted rather than publishing them as company facts.
3. Relationship ledger. Record the legal or operational relationship being claimed—such as owner, parent, operator, manager, employer, licensor, provider, or property owner—along with the exact entity names, effective period, governing document, approval status, and publication limits.

The ledgers should reference one another through stable record IDs, not by copying every field into every system. A facility record can point to its current local-profile access review and to a separately governed operating-entity record. That makes the boundary visible without pretending the three records are interchangeable.

Why the separation matters

When the ledgers collapse, routine maintenance creates avoidable risk. A former agency can remain a profile owner after its engagement ends. A current executive can lack access to a company page. A platform can use a legacy brand while a legal record uses a different entity name. A facility manager can administer hours and reviews without being the property owner. A software administrator can publish release notes without being the product owner or provider.

None of these states is automatically wrong. The problem is failing to name which state has been observed. A visible role, an authenticated permission screen, a filing, a contract, a deed, a trademark record, and a first-party directory each answer different questions. Good governance preserves that difference.

A controlled correction sequence

1. Resolve the exact record. Start with the canonical profile, property, Page, or domain—not a generic search result or a similarly named business.
2. Classify the requested change. Decide whether it changes a public fact, an access role, a verification state, or a legal relationship. More than one ledger may be involved, but each needs its own evidence.
3. Confirm the governing source. Match the field to the source that owns the decision. Office hours may come from an operating schedule; a Page role comes from the authenticated admin view; an operator relationship may require an agreement or approved entity record.
4. Use least necessary authority. Change only the affected field or role. Do not add administrators, transfer primary control, reset credentials, or widen permissions merely because an unrelated correction is needed.
5. Capture the before state. Preserve the exact value, URL, date, role label, and evidence used without exposing passwords, personal identifiers, or customer information.
6. Implement and verify visibly. Save the change, reload the public surface, inspect desktop and narrow layouts when the page is customer-facing, and confirm that links, metadata, and structured data still agree.
7. Reconcile all three ledgers. Record the completed action and any remaining mismatch. A profile correction does not close a legal-evidence gap; a legal confirmation does not prove the public page or access list was updated.
8. Review on separate cadences. Public facts may need monthly review, access roles quarterly review, and legal relationships event-driven review when an agreement, acquisition, disposition, rebrand, or product assignment changes.

A fictional example

Imagine a storage facility whose map profile lists an agency account as primary owner, a regional employee as manager, and the correct public hours. The first ledger says the customer-facing hours are accurate. The second says current access may need recertification because the primary role belongs to an external account. The third remains silent on property ownership and facility operation until the governing company records are reviewed.

The correct action is not to rewrite all three stories at once. Preserve the accurate hours, verify whether the external role is still required, and route legal or operating relationships to their proper source. If the role changes, log invitation, acceptance, transfer, removal, and visible access as separate states. If the public facts change, verify the final profile separately.

Minimum release gate

• The exact profile or property is resolved.
• The requested field belongs to a named ledger.
• The evidence source is current and authorized for that field.
• No platform role is used as legal-relationship proof.
• No legal relationship is used as current-platform-access proof.
• The change uses the least necessary permission and preserves recovery.
• The final public value or access state is visibly verified and dated.
• Submission, acceptance, propagation, indexing, and public display remain separate outcomes.

Primary references

• Google Business Profile Help: Manage your Business Profile owners and managers
• LinkedIn Help: LinkedIn Page admin roles
• LinkedIn Help: Understand admin access for LinkedIn Pages