Tenant separation in cloud ERP

Multi-tenant means many companies use the same application and the same servers. That keeps operating costs down and updates central. It does not mean customer data sits in one shared pot. The critical question is whether the software binds every read and write to an account before anything leaves the database.

As an operator, you care about the outcome: an employee of company A must not see an invoice, contact, or service order of company B. That applies to the UI, exports, global search, and the Account API. If that boundary is missing, encryption and hosting location alone do little.

Jupiter ERP works with accounts as tenants. Each account has its own data space. Access to other tenants’ data is not available in the UI or via interfaces. Shared infrastructure remains; separation lives in application logic and in the queries.

Shared infrastructure covers data center, containers, database clusters, and backup pipelines. Many tenants run on the same machines. That is common and economical. Data separation covers which rows a user may read per request. Mixing the two creates false expectations: “We host in Germany” is not a substitute for account filters on every query.

Technically, Jupiter ERP checks requests that carry entity IDs to confirm the record belongs to the current account. Without that binding, there is no access. Global search returns only hits from your own tenant. The same applies to the Jupiter AI assistant and chat: they work read-only and stay limited to your account.

Enterprise customers can discuss dedicated environments when tenders or internal policies demand stronger isolation. For most SMEs, logical tenant separation is enough, as long as roles, logs, and period locking are used cleanly.

Tenant separation protects you from other companies. Inside your team you need a second boundary: who may see finance, who only field jobs, who may export? Fine-grained rights per module reduce mistakes and limit damage if an account is compromised.

In Jupiter ERP you invite users and assign roles. Accounting sees finance and reports; field technicians work with orders and reports without necessarily opening banking or DATEV export. Who may view the activity log is also controlled by permissions. The log itself is included in every plan and stays tenant-wide.

Roles do not replace organisational clarity. Decide who locks periods, who changes master data, and who matches bank transactions. Software enforces what you store in the role. Responsibility for internal policies stays with you.

GoBD (German principles for proper IT-supported bookkeeping) require traceable, orderly, and unaltered records. That assumes documents and logs stay assigned to the right company. Mixed tenant data makes audits and tax inspections unnecessarily risky: you would have to prove foreign records never entered your reports.

Jupiter ERP supports you with period locking, PDF storage, change logs, and DATEV-compatible export from the Business package. Technical tenant separation is the foundation underneath. Software alone does not replace process documentation or alignment with your tax advisor. It provides the boundary so your processes can be auditable at all.

Under privacy law you are typically the controller for your customers’ and employees’ data in the application. Jupiter ERP processes it as a processor. A data processing agreement (DPA), hosting in Germany, and roles are complementary pieces. Details are on the platform and security pages.

Ask concrete questions: Is every API call and list query bound to the account? Does search return only your own hits? Are there roles per module and a change log? Can you lock periods and export without packing another tenant’s data into the file?

Marketing lines about “enterprise security” help little when answers stay vague. In a trial, check whether a second test account is truly invisible, and whether a user with a limited role cannot open finance. That shows up in a few minutes.

Jupiter ERP is built for SMEs that want cloud convenience and still need clear boundaries. As you grow, modules and user count scale without reinventing tenant logic.