Thrizer Product Constraints & Limitations
Last Updated: 2026-04-02 Status: CanonicalPurpose: Defines the hard system constraints and unsupported behaviors of the Thrizer platform. Use this file when determining what is not possible, what must be structured in a specific way, or why a requested workflow cannot be completed as described. This file should be consulted when: A user asks if a workflow, billing setup, or payment configuration is supported A request involves combining, splitting, or modifying charges, claims, or payments There is ambiguity about system behavior vs. user/insurance behavior An error, limitation, or workaround needs to be explained Multiple actions are being attempted that may conflict with system rules This file provides deterministic system boundaries. It should override assumptions from other files when conflicts arise about what the system can or cannot do.
Payment Constraints
RULE: MULTIPLE-CARDS-PER-SESSION-NOT-SUPPORTED
Type: Deterministic StatementA single session charge cannot be split across multiple payment methods, such as two credit cards. Implications
- Clients must use one payment method to cover the full cost of the session
- If a client wishes to use multiple payment methods, separate charges must be made for each card
- The system cannot bundle charges from multiple cards into one claim submission
RULE: ONE-CHARGE-PER-CLAIM
Type: Deterministic StatementEach charge corresponds to a single claim. Implications
- Charges cannot be combined into a single claim
- Splitting a session into multiple charges results in multiple claims
Billing & Coding Constraints
RULE: SINGLE-CPT-PER-CHARGE
Type: Deterministic StatementEach charge supports only one CPT code. Implications
- Multiple services must be billed as separate charges
- Each CPT code generates its own claim
RULE: NO-AUTOMATIC-BUNDLING
Type: Deterministic StatementThrizer does not support bundling multiple charges into a single claim. Implications
- Manual workarounds (e.g., superbill submission) may be required
- Bundling requests are not supported at the system level
Payout & Financial Constraints
RULE: NO-CLINICIAN-PAYOUT-SPLITS
Type: Deterministic StatementThrizer does not support automated revenue splits between clinicians. Implications
- All payouts go to a single linked bank account
- Practices must manually distribute funds
RULE: SINGLE-BANK-ACCOUNT-PER-TEAM
Type: Deterministic StatementEach team can only have one payout bank account. Implications
- Individual clinicians within a team cannot receive direct payouts
- Team-level financial routing is required
Account & Identity Constraints
RULE: EMAIL-NOT-EDITABLE
Type: Deterministic StatementAccount email addresses cannot be modified after account creation. System Behavior
- The email address is a fixed identifier tied to the account.
- Users must continue using the original email for authentication.
- Create a new account with the desired email
- Add a new email as a team member
- Account access persists as long as valid login credentials are used.
- Email immutability does not prevent access to:
- historical data
- prior transactions
- claims and records
- Email lifecycle outside Thrizer (e.g., deactivation by provider) does not modify the account.
- Users are responsible for maintaining access to their login credentials.
- Email cannot be changed retroactively
- Account identity is permanently bound to the original email
RULE: ONE-ACCOUNT-PER-EMAIL-PER-TEAM
Type: Deterministic StatementAn email address can only be associated with one Thrizer team at a time. Implications
- Users operating across multiple teams must use separate accounts or roles
Payment Method Constraints
RULE: NO-MULTIPLE-CARDS-PER-CHARGE
Type: Deterministic StatementA single charge cannot be processed using multiple cards. Implications
- Full session cost must be charged to one payment method
- Workarounds require separate charges or alternative workflows
RULE: NO-RETROACTIVE-PAYMENT-METHOD-CHANGES
Type: Deterministic StatementCompleted charges cannot be reassigned to a different payment method. Implications
- New payment methods apply only to future charges
Product Behavior Constraints
RULE: THRIZER-PAY-NOT-RETROACTIVE
Type: Deterministic StatementThrizer Pay can only be applied to future sessions. Implications
- Past sessions cannot be converted to Thrizer Pay
- Payment type must be selected before charge submission
RULE: DIAGNOSIS-REQUIRED-FOR-CLAIMS
Type: Deterministic StatementA diagnosis code is required before submitting a charge that generates a claim. Implications
- Claims cannot be submitted without a diagnosis
- Clinicians may delay charging until diagnosis is available
Infrastructure & System Behavior
RULE: THRIZER-AS-PAYMENT-INFRASTRUCTURE
Type: Deterministic StatementThrizer operates as a payment infrastructure layer similar to a payment processor. Implications
- Clinicians are responsible for collecting valid payment methods
- Failed payments require clinician follow-up
- Thrizer does not act as a collections intermediary
Data & Account Management Constraints
RULE: CLIENT-ACCOUNT-INDEPENDENCE
Type: Deterministic StatementClient accounts are structurally independent from clinician accounts Implications
- Clients can be linked to multiple practices
- Moving a client between practices does not require a new account
RULE: LIMITED-ACCOUNT-MUTABILITY
Type: Deterministic StatementCertain account attributes (e.g., email) cannot be modified after creation. Implications
- Structural changes require account recreation or duplication
RULE: NO-SHOW-CANCELLATION-FEES-NOT-SUBMITTED
Type: Deterministic StatementNo-show or cancellation fees cannot be submitted to insurance carriers through Thrizer. Implications
- Clinicians may charge clients directly for missed or canceled sessions but cannot submit these charges for insurance reimbursement through Thrizer.
- These fees should be billed separately as self-pay charges.
- Insurance claims cannot be generated for no-show or cancellation fees, and therefore, clients cannot receive reimbursement through their insurer for these fees.
Notes on Usage
- These constraints are system-level limitations, not insurance or policy decisions
- Workarounds may exist but are not guaranteed to produce correct claim outcomes
- When constraints interact with insurance behavior, outcomes become insurance-dependent
RULE: ACCOUNT-TYPE-IMMUTABILITY-AND-INDEPENDENCE
Type: Deterministic StatementClient accounts and clinician accounts are structurally separate and cannot be converted, merged, or repurposed. System Behavior
- A client account cannot become a clinician account
- A clinician account cannot become a client account
- Accounts cannot be merged or transferred between roles
- Each account type is created and maintained independently within the system
- The same email address may be used to create both:
- a client account
- a clinician account
- These accounts remain fully separate despite sharing the same email
- Users must create a new account if they need a different role
- Data, history, and relationships do not transfer between account types
- Role changes require account duplication, not modification
- No cross-role conversion
- No account merging
- No shared state between client and clinician account objects