Embedded Accounting for SaaS

TL;DRBuilding accounting into your SaaS product is no longer a 12-month engineering project. With an embedded accounting API like gnubok, you can offer end-customer bookkeeping inside your application in weeks, not quarters. This article covers the architecture, the commercial models (rev share, per-tenant, hybrid), the multi-tenant data model, and the actual integration shape.

If your SaaS serves Swedish small businesses or freelancers, you have a structural opportunity: accounting is the highest-stickiness product category in Swedish B2B SaaS. Customers don't leave when their books are inside you. They can't.

The technical lift used to be prohibitive — building accounting infrastructure is a multi-year project. With embedded accounting via gnubok it's a multi-week project. This article is the developer-side overview.

What "embedded accounting" means here

Three operational realities:

1. Your end customers' books live inside your product UI. They don't see gnubok. They don't sign up for gnubok. They sign up for your product, and accounting is a feature.
2. You build the UI on top of an API. The accounting engine, validation, compliance, and bank connections come from us. The interface, navigation, branding, and product integration come from you.
3. You bill end customers as you see fit. gnubok bills you wholesale (rev share, per-tenant, or hybrid). The retail margin is yours.

Common product wrappers:

• E-commerce platforms (offer bookkeeping to their Swedish merchants).
• Freelance/contractor platforms (offer bookkeeping as a tier).
• B2B marketplaces with revenue-share structures (need accurate per-merchant accounting).
• Vertical SaaS for service businesses (consultancies, plumbers, restaurants) where accounting is part of "running your business" in-product.

Architecture in one diagram

┌──────────────────────────────────────────────────────┐
│           Your SaaS product (host)                    │
│  - Your branding, your UX, your URL                   │
│  - End customer auth, billing, product features       │
└──────────────────────────────────────────────────────┘
                       │
                       │ Partner API (scoped per-tenant)
                       ▼
┌──────────────────────────────────────────────────────┐
│        gnubok platform (multi-tenant)                 │
│  - One tenant per end customer                        │
│  - Per-tenant audit log, accounts, periods            │
│  - Tenant isolation enforced at the API and DB level  │
└──────────────────────────────────────────────────────┘
                       │
                       ▼
┌──────────────────────────────────────────────────────┐
│        Swedish compliance + integrations              │
│  - Skatteverket, BankID, BAS chart, BFL              │
│  - PSD2 bank connections via Enable Banking           │
└──────────────────────────────────────────────────────┘

You operate the host. We operate the ledger. End customers see your branding and never know we exist (unless you choose to mention it).

The integration shape

Three primary API surfaces:

1. Tenant provisioning

When a new end customer signs up in your product and you want to enable accounting:

curl -X POST https://app.gnubok.se/api/partner/tenants \
  -H "Authorization: Bearer $PARTNER_TOKEN" \
  -d '{
    "external_id": "user_abc123",
    "company": {
      "org_number": "5595386219",
      "name": "Acme AB",
      "fiscal_year_start": "01-01"
    },
    "initial_users": [
      { "email": "owner@acme.se", "role": "admin" }
    ]
  }'

Returns a tenant ID and per-tenant access tokens scoped for read/write operations on that tenant's books only.

2. Per-tenant operations

Once provisioned, your product calls per-tenant endpoints using tenant-scoped tokens:

# Create a transaction in tenant_xyz's books
curl https://app.gnubok.se/api/transactions \
  -H "Authorization: Bearer $TENANT_TOKEN" \
  -H "X-Tenant-Id: tenant_xyz" \
  -d '{
    "date": "2026-05-12",
    "description": "Customer payment",
    "lines": [...]
  }'

All API surfaces (transactions, invoices, reports, MCP tools) are accessible per-tenant. Tenant isolation is enforced server-side: a tenant token cannot read another tenant's data even if the tenant ID is forged.

3. Cross-tenant management

Your product needs admin views (list tenants, view active vs inactive, billing reconciliation). The partner-scoped key has access to tenant metadata across your customer base:

curl https://app.gnubok.se/api/partner/tenants \
  -H "Authorization: Bearer $PARTNER_TOKEN" \
  -G \
  -d "active=true"

You can not, with partner-scoped credentials, read actual transaction data inside tenants. That requires per-tenant tokens that you generate explicitly for support scenarios.

Building the UI

Two paths:

Path 1: Full custom UI

Build your accounting interface from scratch on top of the gnubok API. Maximum branding control, maximum design integration with the rest of your product. Higher initial effort (2-3 months for a basic UI with reports, invoicing, and a categorization flow), but the result is indistinguishable from a native feature.

This is what most platforms with strong design sensibilities choose.

Path 2: Embeddable components

We maintain a React component library that renders parts of the accounting flow with customizable theming:

import { GnubokLedger, GnubokReports, GnubokInvoices } from "@gnubok/embed";

<GnubokLedger
  tenantToken={tenantToken}
  theme={yourTheme}
  onTransactionCreated={(tx) => trackEvent("accounting.transaction.created")}
/>

Faster to integrate (a week or two for full coverage), less branding control. Reasonable middle ground for platforms that want accounting integrated without becoming an accounting UI company.

The commercial model

Three structures:

Rev share

You charge end customers whatever you want for accounting (typical: 100-300 SEK per active customer per month). gnubok takes a percentage (15-25 percent depending on volume). You retain the relationship and the upside.

Example math:

• 1000 end customers paying 199 SEK/month for accounting
• Gross revenue: 199 000 SEK/month
• gnubok at 20 percent: 39 800 SEK/month
• Net to host: 159 200 SEK/month
• Plus stickiness, plus product upsell into adjacent features

Per-tenant flat

A fixed wholesale cost per active tenant. Typical range:

Volume	Per-tenant cost/month
1-100 tenants	199 SEK
101-1000 tenants	149 SEK
1001-10000 tenants	99 SEK
10000+	Negotiated

Better for hosts that are price-sensitive and confident in their retail pricing.

Hybrid

Low per-tenant base + percentage of premium features (AI categorization, MCP access, advanced reporting). Good for hosts that want a predictable floor plus upside on heavy users.

For most SaaS the math favors rev share above roughly 500 active tenants. Below that, the per-tenant flat fee is simpler and equally cost-effective.

Compliance considerations

Swedish accounting compliance is non-trivial. Three things to know:

1. Books belong to the end customer, not to you

Your end customer is the personuppgiftsansvarig (data controller) and the obligated party under Bokföringslagen. Your platform is a personuppgiftsbiträde (processor). gnubok is an underbiträde (sub-processor). Standard DPA chain.

This means:

• End customers can export their books and leave whenever they want.
• You cannot lock them in.
• You cannot delete their books unilaterally.
• They can pull a complete SIE4 export at any time.

2. Audit log is per-tenant

Every operation in a tenant's books generates an audit entry attributed to:

• The user (end customer's representative, identified via BankID for high-risk ops)
• The session (which UI flow or API call triggered it)
• The originating system (your platform identifier)

Revisors auditing an end customer's books can read this directly. It's complete and immutable.

3. Tax filings flow through Skatteverket

Each tenant has its own Skatteverket authorization. You don't file on behalf of end customers; the end customer authorizes gnubok as their ombud (or files manually). Your platform can surface "file your VAT return" as a feature in your UI, but the actual filing is between the end customer and Skatteverket.

What you should think about before signing

Three pre-integration questions:

1. What percentage of your customers are Swedish? Embedded accounting via gnubok works for Swedish-registered companies. If 80 percent of your customers are international, this is the wrong integration. We're focused on doing one country exceptionally well.

2. Do you have a clear monetization story? Embedded accounting that you give away free is technically possible but commercially questionable. Customers value it because it costs them money to operate. If it's free in your product, it tends to be treated as a low-value feature.

3. Do you have engineering capacity for a 6-12 week initial integration? This is not a weekend project. The first integration is 6-12 weeks for a full-custom UI, 1-3 weeks for embeddable components. After that, ongoing maintenance is minimal.

What's already live

A few categories of platforms have embedded gnubok already:

• A Swedish e-commerce platform offering their merchants automated bookkeeping that ties directly to their order data.
• A freelancer platform that bundles accounting into their premium tier for self-employed consultants.
• A B2B marketplace where vendors have per-vendor accounting tied to marketplace transactions.

In each case, end customers never see gnubok. They see their host platform's UI. The accounting "just works" inside the product they're already using.

What to do next

1. Read the Accounting API for the AI Era to understand the broader product positioning.
2. Read Building on an Open Source Swedish Ledger for the developer-side architecture detail.
3. Contact us via /byraer (yes, that page covers embedded partners too) for a commercial conversation. Volume pricing and integration support are tailored to your specific use case.

Embedded accounting is one of the categorically underrated growth levers for Swedish vertical SaaS. The platforms that integrate it before their competitors will own the customer relationship more deeply than any feature can.

Frequently asked

Why would a SaaS want to embed accounting?

Three reasons: stickiness (customers don't leave when their books are inside you), revenue (per-customer accounting subscription stacks on top of your product price), and data (full visibility into customer financial health enables better product decisions). For verticalized SaaS in e-commerce, freelance platforms, agency tooling, or B2B marketplaces, embedded accounting is often the obvious upsell.

Is this Plaid for accounting?

Closer to Stripe Connect for accounting. Plaid is read-only data aggregation; gnubok embedded is a full transactional ledger that your end customers operate inside your product. Different category, different commercial model. You're not aggregating accounts; you're providing accounting.

What does the data model look like in multi-tenant?

One gnubok tenant per end customer. Your SaaS gets a partner-scoped API key that can provision new tenants, list them, and access their data with explicit per-tenant token scopes. Tenants are fully isolated; one tenant cannot see another's data. Audit log is per-tenant.

What's the commercial model?

Three options: rev share (gnubok takes 15-25 percent of accounting revenue you collect from end customers), per-tenant flat fee (50-200 SEK per active tenant per month), or hybrid (low per-tenant + percentage of premium features). For most SaaS the math works out best with rev share above ~500 active tenants.

Can we white-label completely?

Yes. End customers see only your product. gnubok is the underlying engine but never surfaces. The UI is yours (you build it on top of the API), or you can use a customizable embeddable component that we maintain.