Skip to content

Bill splitting scheme

To meet the needs of bill splitting when multiple projects share resources, and to satisfy management precision and isolation requirements in different scenarios, three types of solutions have been formed. Each solution differs significantly in operational logic, scope of application, and functional characteristics:

Scheme Advantages Disadvantages Application Scenarios
Sub-account Billing Scheme 1. High cost statistical accuracy; can accurately track the cost of each resource call for individual projects, facilitating cost analysis and budget control.
2. Billing data is linked with sub-account operation logs to support cost traceability and meet audit requirements.		 Resource visibility isolation is not implemented; all sub-accounts can view full resource information after logging into the console, posing potential information leakage risks. 1. Scenarios with high requirements for cost accounting accuracy and strong demand for inter-project resource sharing.
2. Teams with unified resource management specifications and good operational compliance of sub-account users.
3. Scenarios requiring frequent cross-project resource scheduling where isolation settings are not expected to affect collaboration efficiency.
Workspace Billing Scheme 1. Achieves full-dimensional and thorough resource isolation (including resource viewing, calling, log access, etc.), and technically eliminates unauthorized cross-project calls.
2. Flexible billing statistical dimensions, supporting hierarchical accounting by Workspace or sub-account to adapt to multi-dimensional management needs.
3. Complies with Level Protection Compliance requirements, effectively reducing the risk of sensitive data leakage.		 The configuration process is relatively complex, requiring multiple operations such as Workspace creation, sub-account configuration, permission assignment, and cross-Workspace resource deployment, which has certain requirements for the professional competence of administrators. 1. Group-type enterprises (with business lines or subsidiaries as independent accounting units and high inter-project information sensitivity).
2. Long-cycle and large-scale projects with extremely high requirements for resource stability and security, where potential risks caused by resource sharing are not allowed.

1. Isolation Solution Based on Sub-accounts

Core Logic: Take sub-accounts as the unit for expense statistics. Configure independent sub-accounts for each project. All resource calling behaviors of the project are executed through sub-accounts. The system will record the operation trajectory of each sub-account and the corresponding resource consumption, and finally generate expense bills by sub-account.

Operation Points:

  • The main account needs to create sub-accounts for each project in the user management module;

  • When a sub-account calls resources, the system will automatically count the cost of the called resources to ensure the accuracy of cost attribution.

Advantage Analysis:

  • The accuracy of expense statistics is high, which can accurately track the cost of each resource call of each project, facilitating cost analysis and budget control;

  • Bill data is linked with sub-account operation logs, making it easy for the audit department to trace the specific reasons for the generation of expenses.

Disadvantage Limitations:

  • Resource visibility is not isolated. After all sub-accounts log in to the console, they can view all resource information in the system, posing a risk of information leakage;

Applicable Scenarios:

  • Scenarios with high requirements for expense accounting accuracy but strong demand for resource sharing between projects;

  • Situations where there are unified resource management specifications within the team and sub-account users have good operating discipline;

  • Scenarios where cross-project resource scheduling is required frequently and it is not desired that isolation settings affect work efficiency.

2. Isolation Solution Combining Workspace and Sub-accounts

Core Logic: Construct a two-layer isolation system of "workspace + sub-account". Each project corresponds to an independent workspace with an exclusive sub-account; the main account assigns permissions to sub-accounts through the console to only access the corresponding workspace. Resources in the workspace are deployed independently and do not communicate with each other. Bills can be counted in both workspace and sub-account dimensions.

Operation Points:

  • The main account needs to first create a workspace and configure an independent environment;

  • Create an exclusive sub-account for each workspace, and strictly limit the operation scope of the sub-account through the permission matrix, allowing access only to resources within the workspace;

  • When deploying resources, the affiliated workspace will be clearly specified to ensure the boundary of resource isolation;

Advantage Analysis:

  • Achieve complete isolation of resources, including resource/log viewing and resource calling, technically eliminating the possibility of cross-project resource calling;

  • The bill statistics dimension is flexible. It can view the overall cost of the project by workspace, or analyze the cost generated by specific operations by sub-account, meeting management needs at different levels;

  • Compliant with equal protection requirements. For projects involving sensitive data, potential risks of data leakage can be reduced through strict isolation settings.

Disadvantage Limitations:

  • The configuration process is complex, requiring the main account to complete multiple operations such as workspace creation, sub-account configuration, permission allocation, and resource deployment to multiple workspaces, which has high requirements for the professional ability of administrators;

Applicable Scenarios:

  • Group enterprises where various business lines or subsidiaries are independent accounting units and projects have high information sensitivity;

  • Scenarios with long project cycles, large scales, extremely high requirements for resource stability and security, and no tolerance for potential risks caused by resource sharing. ```