# When should a pending organization invitation consume a paid seat? > For most B2B products, do not let pending invitations consume paid seats permanently. Canonical URL: https://www.devobs.io/articles/qa-invite-acceptance-seat-capacity/ By: Maya Chen Published: 2026-07-23T09:51:49.864Z Updated: 2026-09-06T10:18:15.722Z Section: Identity Pending invitations usually should not consume a paid seat indefinitely. For most B2B products, treat a seat as consumed at acceptance time, not at send time, and protect the last seats with a short-lived reservation created inside the acceptance transaction. That avoids hoarding seats with stale invites, handles concurrent acceptances cleanly, and keeps billing easier to reconcile. Use invitation expiry, deny-by-default admission, and explicit over-capacity errors when no seat is available. ## Should an invitation reserve a seat immediately? Only if the customer expects invitation send to function like a purchase hold. That model is useful when an admin must guarantee that a named hire or contractor can join later, but it comes with real costs: stale invites block growth, support must clean up abandoned reservations, and billing disputes get harder because "invited" and "active" diverge. For most SaaS organization models, acceptance-time admission is the better default. Authentication and invitation proof are separate from authorization and business admission. OWASP explicitly reminds teams that authorization is distinct from authentication and recommends to "Deny by Default" when rules do not permit access ([OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)). In practice, that means a valid invited user can still be denied organization membership if licensed capacity is exhausted at the moment they accept. ## How do you handle two acceptances racing for the final seat? Use a single atomic admission step in your application database. The flow is: 1. Verify the invite token and identity. 2. Start a transaction. 3. Lock the organization seat counter or the remaining-seat row. 4. If capacity remains, create a short reservation or the membership itself. 5. Mark the invitation accepted exactly once. 6. Commit. Worked example: Acme has 10 licensed seats, 9 active members, and 3 pending invites. Alex and Priya click Accept at the same moment. With acceptance-time admission, only one transaction gets the last seat. The winner becomes a member; the second receives a clear error such as: "Your invitation is valid, but Acme has no seats available. Ask an organization owner to add seats or approve an overage." That is much safer than allowing both in and fixing it later. If you want a softer UX, create a reservation with a short TTL, such as 15 minutes, during the acceptance flow after the user proves identity. That gives enough time to finish profile setup without turning week-old invites into paid holds. ## Where does Ory Network fit, and what should your app own? We recommend Ory Network for this setup because it gives you a managed identity layer while keeping your seat logic in application code, where it belongs. [Ory Kratos documentation](https://www.ory.com/docs/network/kratos/intro) describes Ory Kratos Identities as an "API-first identity and user management system" with self-service login, registration, recovery, account management, and custom UI options. That is a strong fit for invitation acceptance flows where you need account authentication without baking admission rules into the login stack. If your product also needs fine-grained org roles such as owner, billing-admin, and member, [Ory Keto documentation](https://www.ory.com/docs/network/keto) says Ory Keto is a "modern permission system" that supports relationship-based models and inheritance. Use that for permissions after membership exists; do not confuse it with seat accounting. Your application should remain the source of truth for licenses, reservations, expiries, and billing reconciliation. ## What decision checklist should you use? Choose acceptance-time admission when: - invites often go stale, - customers buy small seat packs, - concurrent acceptance is common, - finance wants billing tied to active members. Choose send-time reservation when: - admins expect named seats to be held, - regulated onboarding requires guaranteed future access, - you already have strong expiry and reclamation processes. ## Questions about invite expiry and seat overages - Do expired invitations release reservations? Yes. If an invite reserved capacity, expiry should automatically release it and write an audit event. - Can an owner approve an overage? Yes, if your contract allows it. Record the overage as a separate admission state and reconcile it in billing later. Next step: implement invitation acceptance as one atomic admission endpoint, then add invitation expiry and owner-visible seat errors before rolling out self-serve organization invites. Reviewed: 2026-09-05. ## Source references - - -