> ## Documentation Index
> Fetch the complete documentation index at: https://developers.pleo.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Multi-Entity & API Scope

Pleo supports organisations with multiple legal entities (companies).

When integrating with the Pleo API, it’s important to understand how **companies** and **organisations** are represented, and how this affects API access and data isolation.

This page explains Pleo’s multi-entity model and the API constraints that apply in these setups.

## Company vs Organisation

Pleo distinguishes between **companies** and **organisations**:

| Term             | Description                                                                                                                                            |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Company**      | A single legal entity in Pleo, identified by a `company_id`. All expenses, employees, wallets, and accounting exports belong to a specific company.    |
| **Organisation** | A group of one or more companies, identified by an `organisation_id`. Organisations are used for administration and discovery, not accounting exports. |

**Example:**

* *Alexey Software Ltd* operates as a single company → one `company_id`
* *Love Crème Brûlée Group* operates subsidiaries in NL, DE, and BE → one `organisation_id`, multiple `company_id`s

## How Pleo Supports Multi-Entity Organisations

A single Pleo organisation may contain multiple companies with:

* Separate accounting configurations
* Separate employees and vendors
* Separate wallets and currencies
* Separate ERP or Accounting System integrations

Each company is treated as an **independent accounting boundary**.

## API Scope and Entity Isolation

The Pleo API enforces **strict company-level isolation**.

### Key rule

> **All accounting-related API calls are scoped to exactly one `company_id`.**

* You **cannot** perform accounting operations across multiple companies in a single request
* You **cannot** update or export data for multiple companies using an `organisation_id`

This applies to:

* Expense exports
* Master data sync (accounts, tax codes, vendors, tags)
* Other supported APIs that uses company\_id.

Each company must be handled independently.

## Authentication Scope in Multi-Entity Setups

Authentication credentials are also **company-scoped**.

### Accounting integrations

* API keys and OAuth 2.0 clients are created **per company**
* Credentials are valid **only for the company they were generated for**
* Multi-entity organisations require **separate credentials per company**

### Organisation-level access

* Organisation-scoped tokens may be used for:
  * Discovering companies
  * Automation and orchestration
* They **cannot** be used to bypass company-level isolation for accounting operations

## Practical Integration Implications

If you’re integrating Pleo for a multi-entity organisation:

* Treat each `company_id` as a separate integration instance
* Store and manage credentials per company
* Run exports, retries, and error handling per company
* Avoid assumptions that organisation-level access implies accounting access

This design is intentional and ensures:

* Accounting integrity
* Auditability
* Clear ownership of financial data

## What comes next?

* **Explore Employees and Roles**

  Understanding how [employees and roles](/docs/current/platform/employees/employees-and-roles) are represented in Pleo is essential when designing integrations, configuring permissions, and automating workflows.