Product For Platforms Features Compliance Build vs Buy Countries
Solutions SaaS Platforms E-Commerce Marketplaces Fintechs Accountants
Developers Pricing Docs
Sign in Talk to us Start free sandbox
Use Case: SaaS

Ship invoicing as a SaaS feature, not a side project

The standard model is one entity per customer. That gives every customer isolated data, their own numbering and branding, and compliance behavior that follows their business setup instead of yours. The expensive part is not invoice CRUD. It is keeping tenant isolation, access control, and country behavior correct as you scale.

Start free sandbox View SaaS docs
Who This Is For
Your customers need to issue invoices under their own business identity
You want one entity per customer with isolated numbering, branding, and settings
Your backend already owns customer onboarding or tenant provisioning
Not A Fit
You only invoice from one central business
You want a standalone invoicing app instead of product-level integration
You have no backend control plane for tenant setup
Common Underestimation

Teams underestimate customer-specific tax and entity complexity

The first invoice is easy. The hard part is onboarding each customer with the right entity details, defaults, access model, and country behavior before live documents exist.

Recommended Path

Start with your control plane, not your UI

Most SaaS teams should begin with an account key on the backend and one sandbox customer entity. From there, choose JavaScript SDK for full control, Embed SDK for fastest UI, or React UI for owned components. Keep customer onboarding and access decisions in your control plane first.

JavaScript SDK

Best default for backend-driven tenant workflows.

Embed SDK

Best when you want working invoicing UI quickly.

React UI

Best when you want components you can fully own.

Entity Model

One customer = one entity

Keep tenant identity in your product, and keep invoicing context in Space Invoices. Each entity gets separate documents, settings, branding, and country-specific behavior.

Isolation Per customer
Numbering Per entity
Branding Per entity
Compliance Per entity country
First Sandbox Milestone

Prove one customer end to end

Before you build the whole tenant-facing experience, create one sandbox customer entity, apply branding, issue one invoice, render the PDF, and decide whether users stay in your UI or get direct dashboard access.

01

Create an entity when a customer account is created or activated

02

Apply branding and defaults during onboarding, not after live documents exist

03

Issue documents in the customer entity context

04

Choose whether users stay in your UI, use embed, or get dashboard access

Operational Gotchas
Use account keys for platform operations and entity keys only for isolated tenant-facing flows
Store your tenant ID in metadata so support and reconciliation stay easy
Decide team access early because it changes your user model
Compliance Notes

Each customer entity inherits compliance behavior from its own country and business configuration, not from your platform brand.

EU customers may need VIES validation and reverse-charge handling. Fiscalization and e-invoicing depend on country-specific setup, so validate those flows in sandbox before rollout.

Choose access model See multi-tenancy guide

Start with one workflow, not a whole rewrite

Free sandbox with no time limit. Prove one entity and one invoice flow before deciding how much UI, compliance, and rollout surface you want to own.

Start free sandbox See platform architecture