Which users count as billable SaaS seats? Build a reviewable register

A user directory and a billable-seat register answer different questions. The directory may contain invited people, suspended accounts, administrators and automated service identities. Read the contract's definition of a paid seat and write a rule for each status. A customer who purchased reserved capacity may owe for unused seats, while another agreement may charge for qualifying activity during the month.

Stripe's per-seat pricing model maps a subscription quantity to units such as user licenses. The billing platform does not decide which entries in your product directory satisfy your commercial definition. Assign that responsibility to a named product or commercial owner, and have finance approve how the rule is evidenced before accepting the quantity sent to billing.

For each relevant account, retain a stable identifier, workspace, status and the dates on which billable status changed. The current directory may omit people who left during the period or show an invitation accepted only after the invoice date. A snapshot alone can therefore be insufficient for a contract that bills changes during the month.

Limit the register to the information needed for the reconciliation. Finance usually needs identifiers and status evidence, not the content of users' work. Agree access and retention with the system owner. If the customer wants a supporting list, use the approved customer-visible identifiers rather than exporting an unrestricted internal directory.

Compare the calculated seat count with the subscription quantity and invoice. Investigate duplicate identities, users moved between workspaces and roles excluded by the agreement. Record whether each difference is a data error, a contractual exception or an unresolved interpretation. Avoid clearing the difference through a manual quantity override without preserving why it was justified.

In an illustrative directory of 52 entries, six pending invitations and two service accounts may or may not be billable. The answer depends on the agreed definition. A register that shows each category and its treatment lets the reviewer reproduce the final number, while a note saying '44 active users' leaves eight exclusions unexplained.

Check how the directory represents renamed users, changed email addresses and accounts recreated after a technical problem. Preserve a stable identity link where the evidence supports continuity. A new directory row can represent the same person, while a shared login can conceal several people; neither situation should be resolved by a count alone.

Ask the product owner to demonstrate the intended treatment using a redacted example and the contract's seat rule. Record any account-sharing or reassignment restriction as a commercial question for the appropriate owner. Finance's register should explain the observed identities and approved classification, with unresolved cases separated from ordinary joiners and leavers before the billed quantity is accepted.

Ask the team preparing invoices to retain the count, definition version and exception approvals for each period. Use a small sample of joiners and leavers to test the dates. If the product changes its roles or invitation behavior, review whether the billing rule still means what the contract says before the new status enters production.

For an outsourced finance provider, request a demonstration using a redacted register and one invoice. The deliverable should explain the seat count and unresolved cases, with a clear path back to the source. Keep the customer's approved corrections with the original invoice and verify the next cycle so a temporary manual fix does not become an unexplained recurring quantity.