Northshore Retail
example subsidiary
- Own ledger & chart of accounts
- Isolated at the data layer
- Own audit history

Bring a new legal entity or operating unit into the workspace with structure that reporting and permissions can use from day one — not a spreadsheet of company codes.

Teams access each company's books from one product while keeping the underlying ledgers separate. Parallel finance operations no longer require separate accounting-system logins.

Move between companies, books, and workflows in the same environment. The team stays oriented while each set of books remains separate.

Hosted P&L, balance-sheet, and operational views stay tied to the same ledger each company writes to. Consolidated statements are outside the current public API contract.
Entity Layer
Multi-entity is not another company record in a settings screen. It is isolated books, source-entity journals, and controlled collaboration — the same primitives Paprel uses for every tenant.
Every company gets its own ledger, chart of accounts, and audit history. Isolation is scoped at the data layer, not left to application filters.
Create a company with POST /v1/company and the books come with it — ready for journals, documents, and reporting without a separate finance stack.
Operators move between entities inside the same product. Finance teams stay oriented without opening a second accounting system.
Keep each company's financial reports tied to the isolated ledger and chart of accounts that produced them.
Look up the ledger impact of an order, payout, or invoice with GET /v1/accounting/journals/for-entity using the IDs your product already owns.
Give operators access to the books they run and keep finance leaders visible across the structure — without sharing credentials across entities.
Tenancy model
Provision connected companies with their own books. Configure tenant permissions and validate access boundaries for your deployment.
Isolation is documented in how a company is the boundary. Source-entity lookup uses the Journal API. For destination-app limits, see the QuickBooks API alternative and the marketplace accounting guide.
Your platform
one tenant per customer · OAuth-scoped tokens
Northshore Retail
example subsidiary
Harbor Franchise Co
example operating unit
Atlas Seller Books
example marketplace seller
Illustrative operating units — not customer case studies.
Isolation sits below application code. Every journal, invoice, and report is company-scoped at the data layer.
How it ships
Platforms do not need a second accounting product for the second entity. Provision the company, post against your own IDs, and keep review inside the product.
Create the entity with POST /v1/company. Paprel stands up the ledger, a default chart of accounts, and document numbering in the same call.
Each company is a hard boundary. Journals, invoices, expenses, and reports stay inside that company's books.
Tie journals to the order, payout, property, or loan ID your product already stores. Retrieve the accounting trail later without a mapping spreadsheet.
Operators switch between company workspaces for day-to-day work while each ledger and its reports remain separate.
Where it lands
Whether you serve operators, sellers, property managers, or funds, the pattern is the same: one company boundary, isolated books, journals keyed to your records.
Franchises, locations, and client entities with isolated books inside the industry workflow.
Vertical SaaS accounting
Seller books, settlement journals, and payout trails keyed to your order and merchant IDs.
Marketplace seller books
Owners, LLCs, and portfolios as separate books that managers access from one workspace.
Property management books
Funds, SPVs, and lending entities as isolated ledgers with audit-ready history.
Lending and fund ledgers
Multi-entity accounting keeps a separate set of books for each legal entity or operating unit — own ledger, chart of accounts, and reporting — while customers still work inside one product. Paprel exposes that as an API: provision a company, isolate reads and writes at the data layer, and look up journals by the IDs your product already stores.
Yes. Each company is provisioned with its own ledger, chart of accounts, and document numbering. Your product can create those companies over the API and keep day-to-day work inside the same embedded accounting layer.
Company-scoped access separates accounting entities. Confirm the enforcement design and privileged access paths for your deployment.
Yes. GET /v1/accounting/journals/for-entity takes the entity_type and entity_id your product already stores — an order, payout, invoice, or loan — and returns the balanced journal behind it.
Access is role-aware and company-scoped. Operators can work inside the entities they run, while finance leaders keep visibility across the structure without sharing a single set of credentials.
Reports stay on the same ledger each company writes to and are reviewed within that company's books. Formal consolidation, intercompany eliminations, and consolidated financial statements are not part of the current public API contract.
Adjacent modules
Each company starts with its own account structure and can extend it as the books grow.
P&L, balance sheet, and trial balance from the same ledger each entity posts to.
Scoped roles so operators see their books and finance still reviews across entities.
These workflows ship inside your product through the same endpoints, signed webhooks, and MCP tools proven in production today. Sandbox keys are self-serve — post a journal before you talk to anyone.
{
"company_name": "Northshore Retail Ltd",
"company_signature": "…",
"company_type": "…",
"currency_id": "…",
"contact_email": "finance@northshore.example"
}/v1/company/v1/company/list/v1/accounting/journals/for-entityLive paths from the OpenAPI spec — same wire format in sandbox and production.
Talk to Paprel about company provisioning, isolated ledgers, and journals keyed to the records your platform already owns.