# Billit

> Billit is a European e-invoicing and billing SaaS that helps entrepreneurs, SMEs, large enterprises, accountants, and public institutions create, send, receive, and process invoices over the Peppol network. Founded in Ghent (Belgium) in 2014, Billit serves 255,000+ users across Belgium, the Netherlands, Luxembourg, and Germany and operates a certified Peppol Access Point.

Structured e-invoicing via Peppol is mandatory in Belgium since 1 January 2026; Billit is Peppol-ready by default. The platform covers sales invoicing, quotes, credit notes, OCR-based expense capture, automatic booking, recurring invoices, bank reconciliation, payment links and QR codes, and accountant collaboration. It ships with iOS and Android apps, 100+ integrations with banks/ERPs/CRMs/payment providers/accounting software, and a public REST API. Pricing is consumption-based (from €7.50/month after a free 15-day trial) on processed documents rather than seats. The site is published in Dutch, French, German, and English across market-specific portals (BE, NL, LU, DE, en-int). Canonical product paths below default to nl-be (the largest, most complete portal); equivalent pages exist in other locales — see "Localized portals".

For developers: Billit exposes a JSON REST API at `api.billit.be`, with separate sandbox and production environments. Authentication is via an `ApiKey` request header (or `Authorization` access token), and a `PartyID` header identifies which company a request operates on. Invoices, quotes, and credit notes are all `Order` resources, customers auto-create on first use, totals are calculated server-side, and list endpoints support OData filtering. Anything not in the base schema is set via `CustomFields` mapped to Peppol UBL paths. See the "API" section for environments, headers, the resource model, verified list and create examples, and authoritative documentation links.

## API

Billit's public REST API is JSON over HTTPS, hosted at `api.billit.be`. Every request is authenticated via an `ApiKey` (or `Authorization` access token) header and scoped to a company by the `PartyID` header. Sandbox and production are fully separate environments — separate keys, separate data, identical schema — so the same client code works in both by swapping the base URL and key.

**Scope.** The API covers e-invoicing and document workflows: orders (sales and purchase invoices, quotes, credit notes), parties (customers and suppliers), files (PDFs and attachments), Peppol send and receive, expenses, and webhooks. It does **not** cover payroll, full bookkeeping ledgers, VAT return filing, or banking transactions — those live in adjacent systems Billit integrates with.

### Quickstart (60 seconds to a successful call)

1. Sign up at [my.sandbox.billit.be](https://my.sandbox.billit.be/) for a free sandbox company.
2. In the sandbox app, go to **Settings → API keys** and create a key.
3. Verify your credentials and discover your `PartyID`s by calling the account-information endpoint. It needs only the `ApiKey` header (no `PartyID` yet) and returns the companies your user has access to:

```bash
curl "https://api.sandbox.billit.be/v1/account/accountInformation" \
  -H "ApiKey: $BILLIT_SANDBOX_KEY" \
  -H "Accept: application/json"
```

A 200 response means auth works. Read `PartyID` from any item in the `Companies` array — that's the value to send in the `PartyID` header on subsequent calls.

When ready, swap `api.sandbox.billit.be` for `api.billit.be` and the sandbox key for a production key. No other code changes.

### Environments

- **Production** — `https://api.billit.be` — Live environment. Invoices created here are legally valid and can be transmitted over Peppol. Interactive Swagger reference at `https://api.billit.be/swagger/ui/index`.
- **Sandbox** — `https://api.sandbox.billit.be` — Free test environment for development, automated tests, and Peppol send/receive dry-runs. No real invoices are issued.

### Authentication

Billit supports two authentication methods, both passed as request headers:

- **API key** (recommended for server-to-server) — `ApiKey: <secret-id>`
- **Access token** (OAuth-style) — `Authorization: <access-token>`

Use one or the other, not both. API keys are issued per environment from the Billit web app. Treat keys and tokens as secrets: store them in environment variables or a secret manager, never commit them to source control, and rotate on suspected compromise.

In addition to authentication, every call needs a **`PartyID`** header identifying which company (party) the call operates on. If the caller is an accountant operating on behalf of a client, also send **`ContextPartyID`** for the client party. See "Required headers" below.

### Resource model

A few naming conventions and behaviors are non-obvious and worth knowing up-front:

- **Orders, not invoices.** Sales invoices, purchase invoices, quotes, and credit notes are all `Order` resources, distinguished by `OrderType` (`Invoice`, `Quote`, `CreditNote`, etc.) and `OrderDirection` (`Income` for sales, `Cost` for purchases). The list endpoint is `/v1/orders` — there is no `/v1/invoices`.
- **Parties, not contacts.** Customers, suppliers, and your own company are all `Party` resources, distinguished by `PartyType` (`Customer`, `Supplier`, etc.). Each party can carry multiple `Identifiers` (VAT number, GLN, Peppol participant ID).
- **Customers auto-create on first invoice.** When you POST an order, Billit tries to match the embedded `Customer` against existing parties (by VAT number, email, address, or `Nr`). If no match is found, a new party is created automatically — no separate "create customer" call is needed.
- **Totals are calculated server-side.** Send `Quantity`, `UnitPriceExcl`, and `VATPercentage` per line; Billit computes line totals, VAT, and document totals. This avoids rounding mismatches at validation. See the [calculations doc](https://docs.billit.be/docs/calculations).
- **Currency defaults to EUR.** Set `Currency` (ISO code) explicitly only when invoicing in another currency.
- **Custom Fields are the extension point.** Anything not in the base schema (Peppol UBL paths like `Invoice.AccountingCost`, delivery location IDs, contract references, supplier/customer contact blocks, line-level item identifiers, etc.) is set via a `CustomFields` object on the order or order line. Field names are dot-paths matching the Peppol UBL element. For credit notes, replace the `Invoice.` prefix with `CreditNote.`. See [custom fields](https://docs.billit.be/docs/custom-fields-credit-note) and the header / line custom-field references in the developer docs.
- **Files.** PDFs and other attachments are referenced by `FileID` (UUID) and fetched via the file endpoints rather than embedded inline.

### Required headers

Headers Billit accepts on requests **to** the API:

| Header | Value | Purpose |
|---|---|---|
| `ApiKey` | Your secret API key | Authentication (option 1) |
| `Authorization` | Access token | Authentication (option 2) |
| `PartyID` | Integer — your party (company) ID | Defines which company the request operates on. Required when your account spans multiple companies. |
| `ContextPartyID` | Integer — a client's party ID | Used by accountants to act on behalf of a client party. |
| `Idempotent-Key` | Unique client-generated string | Make a request idempotent — safe to retry without creating duplicates. Note the spelling: `Idempotent-Key`, not the more common `Idempotency-Key`. |
| `StrictTransportType` | `true` | Force strict transport behavior — fail rather than fall back to an alternative method (e.g. don't fall back to email if Peppol delivery isn't available). |
| `Accept` | `application/json` | Recommended on every request. |
| `Content-Type` | `application/json` | Required on `POST`, `PUT`, `PATCH`. |

Headers Billit sends **from** the API (on webhooks):

| Header | Value | Purpose |
|---|---|---|
| `Billit-Signature` | Timestamp + encrypted signature | Verify the webhook payload originated from Billit. Validate this on every webhook receiver. |

### Get account information (verified example)

`GET /v1/account/accountInformation` returns the authenticated user's profile (`Email`, `FirstName`, `LastName`) and the `Companies` array — every party the user has access to, fully populated. Use this call to discover valid `PartyID` values, IBAN/BIC, Peppol identifiers, default transport types, and bank-account details for each company.

```bash
curl "https://api.billit.be/v1/account/accountInformation" \
  -H "ApiKey: $BILLIT_API_KEY" \
  -H "Accept: application/json"
```

Each item in `Companies` is a `Party` with fields including `PartyID`, `Name`, `VATNumber`, `PeppolIdentifier`, `IBAN` / `BIC`, `BankAccounts`, `Addresses`, `DefaultTransportTypeTC`, `DefaultPaymentMethodTC`, and `Identifiers`. This is the canonical schema for Party objects throughout the API — the same shape appears as the `CounterParty` on orders, the `Customer` on invoices, and so on.

### List invoices (verified example)

`GET /v1/orders` returns a paginated list of orders (invoices, quotes, credit notes — see "Resource model"). The response is wrapped in `{ "Items": [ ... ] }`. List responses contain a summary projection of each order, not the full document; fetch a single order by ID for complete data.

Filter using OData query parameters. To list only sales invoices (sent to your customers):

```bash
curl -X GET "https://api.billit.be/v1/orders?\$filter=OrderType+eq+'Invoice'+and+OrderDirection+eq+'Income'" \
  -H "ApiKey: $BILLIT_API_KEY" \
  -H "PartyID: $BILLIT_PARTY_ID" \
  -H "Accept: application/json"
```

Sample response (one item shown, fields truncated):

```json
{
  "Items": [
    {
      "OrderID": 125478,
      "OrderType": "Invoice",
      "OrderDirection": "Income",
      "OrderNumber": "QS-001",
      "OrderDate": "2024-01-01T00:00:00",
      "ExpiryDate": "2024-01-31T00:00:00",
      "OrderStatus": "ToSend",
      "TotalExcl": 17.50,
      "TotalIncl": 19.68,
      "TotalVAT": 2.18,
      "ToPay": 19.68,
      "Paid": false,
      "Overdue": true,
      "DaysOverdue": 39,
      "Currency": "EUR",
      "PaymentReference": "+++001/1800/63503+++",
      "OrderPDF": { "FileID": "c1cd2bfa-3678-42dd-99f3-2f6d323bd2fc" },
      "CounterParty": {
        "PartyID": 125999,
        "DisplayName": "Billit",
        "VATNumber": "BE0563846944",
        "PartyType": "Customer",
        "Identifiers": [ { "IdentifierType": "GLN", "Identifier": "5430003732007" } ]
      }
    }
  ]
}
```

Common filter recipes:

| Goal | OData filter |
|---|---|
| Sales invoices | `OrderType eq 'Invoice' and OrderDirection eq 'Income'` |
| Purchase invoices | `OrderType eq 'Invoice' and OrderDirection eq 'Cost'` |
| Unpaid sales invoices | `OrderType eq 'Invoice' and OrderDirection eq 'Income' and Paid eq false` |
| Overdue | `Overdue eq true` |
| Issued in 2025 | `OrderDate ge 2025-01-01 and OrderDate lt 2026-01-01` |

See the [OData reference](https://docs.billit.be/docs/odata) for the full query syntax (`$filter`, `$top`, `$skip`, `$orderby`, `$select`).

### Create an invoice (verified example)

`POST /v1/orders` creates an order. The same endpoint creates sales invoices, purchase invoices, quotes, and credit notes — the `OrderType` and `OrderDirection` fields determine which. The response is a single integer: the new `OrderID`. Store it on your side; you'll need it to send, retrieve, or credit the order later.

A minimal sales invoice (`OrderDirection: Income`) — Billit will auto-create the customer if it doesn't already exist, and will calculate all totals server-side:

```bash
curl -X POST "https://api.billit.be/v1/orders" \
  -H "ApiKey: $BILLIT_API_KEY" \
  -H "PartyID: $BILLIT_PARTY_ID" \
  -H "Idempotent-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{
    "OrderType": "Invoice",
    "OrderDirection": "Income",
    "OrderNumber": "QS-001",
    "OrderDate": "2025-09-01",
    "ExpiryDate": "2025-10-30",
    "Customer": {
      "Name": "Billit",
      "VATNumber": "BE0563846944",
      "PartyType": "Customer",
      "Email": "buyer@example.com",
      "Addresses": [{
        "AddressType": "InvoiceAddress",
        "Street": "Oktrooiplein",
        "StreetNumber": "1",
        "City": "Ghent",
        "Zipcode": "9000",
        "CountryCode": "BE"
      }]
    },
    "OrderLines": [
      { "Quantity": 1, "UnitPriceExcl": 10.00, "Description": "Box of cookies", "VATPercentage": 6 },
      { "Quantity": 2, "UnitPriceExcl": 3.75, "Description": "Sticks", "VATPercentage": 21 }
    ]
  }'
```

Common header-level fields beyond the minimum: `Reference` (buyer's PO number — one only, no extra text), `OrderTitle` (other buyer reference), `PaymentReference` (structured OGM or free text — Billit auto-generates one if omitted), `DeliveryDate`, `Currency` (defaults to EUR), `Comments` (free text shown on the PDF). For richer Peppol UBL fields (project reference, contract reference, accounting cost, tax representative party, delivery location, line-level item identifiers, etc.), use `CustomFields` — see [Create First Invoice docs](https://docs.billit.be/docs/create-first-invoice) and the custom-fields references.

**Validation errors** return HTTP 4xx with this shape:

```json
{
  "errors": [
    { "Code": "InvalidVAtPercentageForTaxCountry_0_", "Description": "Invalid VAT percentage for country code BE" }
  ]
}
```

After creating an order it lives in Billit but isn't yet sent. Use the **send command** described next to deliver it over Peppol, email, or another channel.

### Send an invoice (verified example)

`POST /v1/orders/commands/send` dispatches one or more existing orders. The same endpoint covers Peppol, email, and other channels — the channel is selected by `Transporttype`. **On success the response is HTTP 200 with an empty body** — agents that expect JSON will misread silence as failure if not handled.

```bash
curl -X POST "https://api.billit.be/v1/orders/commands/send" \
  -H "ApiKey: $BILLIT_API_KEY" \
  -H "PartyID: $BILLIT_PARTY_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "Transporttype": "Peppol",
    "OrderIDs": [2602961]
  }'
```

Body shape: `{ "Transporttype": "<type>", "OrderIDs": [<id>, ...] }`. The other plausible-looking shape — `{ "Transactions": [{ "OrderID": ..., "Transporttype": ... }] }` — returns `ListOfOrdersToSendIsRequired`.

**Transport types.** Common values:

| Value | Channel | Customer prerequisite |
|---|---|---|
| `Peppol` | Peppol network (BE/EU) | Customer party has a Peppol-resolvable identifier. For BE companies, setting `Customer.VATNumber` is sufficient — Billit derives the participant ID (e.g. `0208:0563846944`) automatically. |
| `SMTP` | Email | `Customer.Email` is set to a valid address. |

`Email` is **not** a valid transport type and returns `Invalid transport type` — use `SMTP`. See [transport types](https://docs.billit.be/docs/types) for the full list including letter and country-specific channels.

**Side effects of a successful send.** `OrderStatus` transitions `ToSend` → `ToPay`, `IsSent` flips to `true`, and a new entry is appended to the order's `Messages` array with `TransportType`, `Destination`, `Trials`, `CreationDate`, and (once the transport confirms) `Success: true`. Re-sending the same order on a different transport is allowed and appends another `Messages` entry rather than erroring or creating a new order — useful for multi-channel delivery and retries.

**Tracking delivery.** Two fields on the order, refreshable via `GET /v1/orders/{OrderID}`:

- `CurrentDocumentDeliveryDetails` — `{ IsDocumentDelivered, DocumentDeliveryStatus, DocumentDeliveryDate, DocumentDeliveryInfo }`. Peppol typically completes synchronously (status `Delivered` already set when the send response returns); SMTP enters `Pending` and resolves asynchronously.
- `Messages[*].Success` — flips to `true` once the transport confirms delivery.

For production, prefer webhook subscriptions on `EntityType: Order` over polling.

**Common send errors.**

| Code | Meaning | Fix |
|---|---|---|
| `ListOfOrdersToSendIsRequired` | Wrong body shape | Use `{ "Transporttype": "...", "OrderIDs": [...] }`, not `Transactions: [...]` |
| `TheCustomerIsNotActiveOnPeppol` | Customer has no Peppol identifier or isn't on the Peppol SML | PATCH `VATNumber` onto the customer party (see "Update a party"), or fall back to `SMTP` |
| `TheCustomer_0_DoesNotHaveAValidEmailAddress` | SMTP transport but no `Customer.Email` | PATCH `Email` onto the customer party |
| `Invalid transport type` | Sent `Email` (or another invalid value) | Use `SMTP` for email |

**Pre-flight pattern.** Before calling send, fetch the customer party and verify the prerequisite for the chosen transport (Peppol → `VATNumber` set; SMTP → `Email` set). If missing, either `PATCH /v1/parties/{PartyID}` to add it (see "Update a party") or fall back to the other transport. Setting `StrictTransportType: true` on the request disables fallback and forces a hard fail if the chosen transport can't deliver — useful when you specifically need Peppol delivery to succeed or fail loudly.

### Update a party (verified example)

`PATCH /v1/parties/{PartyID}` partial-updates a party record (customer, supplier, or own company). Send only the fields you want to change. Returns HTTP 200 with empty body.

```bash
curl -X PATCH "https://api.billit.be/v1/parties/1079522" \
  -H "ApiKey: $BILLIT_API_KEY" \
  -H "PartyID: $BILLIT_PARTY_ID" \
  -H "Content-Type: application/json" \
  -d '{"Email": "buyer@example.com"}'
```

Commonly-patched fields: `Email`, `VATNumber`, `Phone`, `Addresses`, `Identifiers`, `IBAN`. Top-level fields can be set directly — they don't need to be nested under `Identifiers`. In particular, setting `VATNumber` on a BE party is sufficient to make the party Peppol-resolvable; Billit derives the Peppol participant ID (`0208:<KBO>`) at send time.

Most common reason to call this: a send command failed with `TheCustomer_0_DoesNotHaveAValidEmailAddress` or `TheCustomerIsNotActiveOnPeppol`. PATCH the missing field on, then retry the send.

### Common tasks

Fast index from intent to endpoint or doc, for the operations most developers actually need:

| Task | How |
|---|---|
| Get my user + list of companies I can access | `GET /v1/account/accountInformation` (no `PartyID` header needed) |
| List sales invoices | `GET /v1/orders` with `$filter=OrderType eq 'Invoice' and OrderDirection eq 'Income'` |
| List purchase invoices (received) | `GET /v1/orders` with `$filter=OrderType eq 'Invoice' and OrderDirection eq 'Cost'` |
| List unpaid / overdue invoices | OData filters on `Paid eq false` or `Overdue eq true` |
| Get a single order by ID | `GET /v1/orders/{OrderID}` (full document, not the list summary) |
| Create sales invoice | `POST /v1/orders` with `OrderType: Invoice, OrderDirection: Income` |
| Create credit note | `POST /v1/orders` with `OrderType: CreditNote`. In `CustomFields`, swap the `Invoice.` prefix for `CreditNote.` |
| Create quote | `POST /v1/orders` with `OrderType: Quote` |
| Send invoice over Peppol | `POST /v1/orders/commands/send` with `{"Transporttype": "Peppol", "OrderIDs": [...]}` — see "Send an invoice" |
| Send invoice via email | `POST /v1/orders/commands/send` with `{"Transporttype": "SMTP", "OrderIDs": [...]}` — note `SMTP`, not `Email` |
| Track delivery status | `GET /v1/orders/{OrderID}`, read `CurrentDocumentDeliveryDetails` and `Messages[]`, or subscribe to webhooks on `EntityType: Order` |
| Add a customer | No separate call needed — embed `Customer` in the order; Billit auto-creates parties on first use |
| Update a customer / supplier | `PATCH /v1/parties/{PartyID}` with the fields to change — see "Update a party" |
| Attach a PDF | Use `AdditionalDocumentReference` in `CustomFields` — see [header custom fields](https://docs.billit.be/docs/extend-content) |
| Set delivery location (GLN) | `Invoice.Delivery.DeliveryLocation.*` in `CustomFields` — see [delivery location](https://docs.billit.be/docs/delivery-location) |
| Override supplier/customer contact for one invoice | `Invoice.AccountingSupplierParty.Party.Contact.*` / `Invoice.AccountingCustomerParty.Party.Contact.*` in `CustomFields` — see [contacts](https://docs.billit.be/docs/contacts-extra-fields) |
| Acting as accountant for a client | Add `ContextPartyID: <client-party-id>` header on every call |
| React to invoice status changes | Subscribe to webhooks — see "Webhooks" below |

### Webhooks

Subscribe to webhooks to be notified of state changes (invoice sent, payment received, Peppol delivery succeeded or failed, document received) instead of polling `/v1/orders`.

**Subscription lifecycle.** Manage webhooks entirely via the API:

| Method | Endpoint | Purpose |
|---|---|---|
| `POST` | `/v1/webhooks` | Create a subscription. Response includes the `Secret` used to verify incoming events — store it; it isn't returned again. |
| `GET` | `/v1/webhooks` | List all subscriptions for the current account (without secrets). |
| `DELETE` | `/v1/webhooks/{webhookID}` | Unsubscribe. |
| `POST` | `/v1/webhooks/refresh/{webhookID}` | Rotate the secret if it leaks. |

Create-request body:

```json
{
  "EntityType": "Order",
  "EntityUpdateType": "I",
  "WebhookURL": "https://your-app.example.com/billit-events"
}
```

Create-response:

```json
{
  "WebhookID": 12345,
  "EntityType": "Order",
  "EntityUpdateType": "I",
  "WebhookURL": "https://your-app.example.com/billit-events",
  "Secret": "<store-this-now>"
}
```

**Subscriptions are environment-scoped.** Sandbox webhooks fire only on sandbox events; production webhooks fire only on production events.

**Payload shape.** Billit POSTs JSON with the entity ID and an `EntityType` discriminator, e.g.:

```json
{ "OrderID": 12345, "EntityType": "Order", ... }
```

**Signature verification.** Every webhook carries a `Billit-Signature` header containing a timestamp and HMAC-SHA-256 signature, comma-separated:

```
Billit-Signature: t=1657133145,s=479f86b8baa181b97281b767b8db125cc312d18b3e611d6157571abcd539f09f
```

To verify a webhook on receipt:

1. **Parse the header.** Split on `,` then on `=` to extract the timestamp `t` and signature `s`.
2. **Rebuild the signed payload.** Concatenate `<timestamp>` + `.` + `<raw-json-body>`. Use the *raw* request body, not a re-serialized version — re-serializing can change whitespace or key order and invalidate the signature.
3. **HMAC-SHA-256.** Hash the signed payload using your stored secret as the key. The hex digest must equal `s`. Use a constant-time comparison.
4. **Optional: replay protection.** Reject the request if `t` is more than your tolerance (e.g. 5 minutes) from the current time.

Reference verification (Node.js):

```js
const crypto = require("crypto");

function verifyBillitSignature(rawBody, headerValue, secret, toleranceSec = 300) {
  const parts = Object.fromEntries(headerValue.split(",").map(p => p.split("=")));
  const { t, s } = parts;
  if (!t || !s) return false;
  if (Math.abs(Date.now() / 1000 - Number(t)) > toleranceSec) return false;
  const expected = crypto.createHmac("sha256", secret).update(`${t}.${rawBody}`).digest("hex");
  return crypto.timingSafeEqual(Buffer.from(expected, "hex"), Buffer.from(s, "hex"));
}
```

**Receiver hygiene.** Return `2xx` quickly and queue downstream work asynchronously. Treat handlers as idempotent — assume any event may arrive more than once and key your processing on the entity ID + a status value rather than re-running side effects blindly.

### Conventions

- **Idempotency** — For state-changing requests (creating an order, sending a Peppol document), generate a unique `Idempotent-Key` client-side. Retrying with the same key is safe and will not create duplicates. Note the spelling: `Idempotent-Key`, not `Idempotency-Key`.
- **List filtering (OData)** — List endpoints accept OData query parameters: `$filter`, `$top`, `$skip`, `$orderby`, `$select`. List responses wrap items in `{ "Items": [ ... ] }`. Field names in filters are PascalCase and case-sensitive (`OrderType`, not `ordertype`). Quote string values with single quotes; ISO-8601 dates without quotes. See [OData reference](https://docs.billit.be/docs/odata).
- **Errors** — Standard HTTP status codes. Validation errors return `{ "errors": [ { "Code": "...", "Description": "..." } ] }`. `401` = missing or invalid `ApiKey` / `Authorization`; `403` = authenticated but lacking access to the requested `PartyID`; `429` = rate limited.
- **Rate limits** — Per-key throttling applies. Respect `Retry-After` on `429`.
- **Multi-company** — Always set `PartyID` explicitly rather than relying on a default; this prevents an action from accidentally targeting the wrong company. When the caller is an accountant, also set `ContextPartyID` to the client party.

### Developer resources

There is no official Billit SDK. Build clients directly against the API or generate one from the Swagger spec; the Postman collection is the closest equivalent to a quickstart kit.

- [Swagger / OpenAPI reference](https://api.billit.be/swagger/ui/index): Interactive API console with full endpoint documentation, request/response schemas, and try-it-now calls. Authoritative source for endpoint paths and parameters.
- [Postman quickstart collection](https://www.postman.com/billit/billit-quickstart-guide/collection/fe4bsae/billit-api-quickstart-guide): Importable Postman collection with example requests for the most common flows. Best starting point for hands-on exploration.
- [Developer documentation root](https://docs.billit.be/): Conceptual guides covering authentication, headers, webhooks, and integration flows.
- [How it works (API basics)](https://docs.billit.be/docs/how-it-works-based-on-api): Authentication and integration walkthrough — start here.
- [Header values reference](https://docs.billit.be/docs/header-values): Authoritative list of accepted request headers (`ApiKey`, `Authorization`, `PartyID`, `ContextPartyID`, `Idempotent-Key`, `StrictTransportType`) and webhook signature header (`Billit-Signature`).
- [OData query reference](https://docs.billit.be/docs/odata): Filter, sort, page, and project list responses with OData syntax.
- [Create first invoice](https://docs.billit.be/docs/create-first-invoice): Walkthrough of `POST /v1/orders` — minimal and advanced JSON bodies, customer auto-creation, validation, multi-company headers.
- [Calculations](https://docs.billit.be/docs/calculations): How Billit computes line and document totals server-side (avoids rounding mismatches).
- [Custom Fields (header)](https://docs.billit.be/docs/extend-content): Header-level Peppol UBL extensions — `Invoice.AccountingCost`, `Invoice.ProjectReference.ID.Text`, `Invoice.ContractDocumentReference.ID.Text`, `PaymentTerms`, `PaymentMeansCode`, `AdditionalDocumentReferenceN`, `Invoice.TaxRepresentativeParty.*`, etc.
- [Custom Fields — supplier & customer contacts](https://docs.billit.be/docs/contacts-extra-fields): Per-invoice contact override for `Invoice.AccountingSupplierParty.Party.Contact.*` and `Invoice.AccountingCustomerParty.Party.Contact.*`.
- [Custom Fields — delivery location](https://docs.billit.be/docs/delivery-location): `Invoice.Delivery.DeliveryLocation.*` for GLN-coded or free-text delivery addresses.
- [Custom Fields — line level](https://docs.billit.be/docs/extend-content-line): Per-line extensions — `PeppolUnitCode`, `PeppolLineID`, `InvoiceLine.Note`, `InvoiceLine.InvoicePeriod.*`, `InvoiceLine.Item.StandardItemIdentification.*` (GTIN), `InvoiceLine.Item.BuyersItemIdentification.*`, `CommodityClassification*`, `AdditionalItemProperty*`.
- [Custom Fields for credit notes](https://docs.billit.be/docs/custom-fields-credit-note): For credit notes (`OrderType: CreditNote`), replace the `Invoice.` prefix with `CreditNote.` in custom field names.
- [Transport types](https://docs.billit.be/docs/types): Channels available to the send command — Peppol, email, etc.
- [Webhook API reference](https://docs.billit.be/reference/webhook): Create, retrieve, delete, and refresh-secret endpoints for webhook subscriptions.
- [Developer landing page](https://www.billit.eu/nl-be/voor-wie/ontwikkelaars/): Marketing overview, use cases, and getting-started links.

## Product

- [Platform overview (English, international)](https://www.billit.eu/en-int/): English landing page summarizing features, audiences, and Peppol e-invoicing.
- [All features](https://www.billit.eu/nl-be/functies/alle-features/): Full catalog of invoicing, expense, automation, and collaboration features.
- [Sales / income](https://www.billit.eu/nl-be/functies/inkomsten/): Quotes, sales invoices, credit notes, payment links, QR codes, automated reminders.
- [Expenses](https://www.billit.eu/nl-be/functies/uitgaven/): Receipt scanning, supplier-invoice intake via email and Peppol, approvals.
- [Automatic processing](https://www.billit.eu/nl-be/functies/automatische-verwerking/): OCR, auto-booking, recurring invoices, bank reconciliation.
- [Extra features](https://www.billit.eu/nl-be/functies/extra-features/): Branding, multi-user, multi-company, advanced workflows.
- [Mobile app](https://www.billit.eu/nl-be/functies/billit-app/): iOS and Android apps for invoicing and receipt capture on the go.
- [Integrations directory](https://www.billit.eu/nl-be/functies/integraties/): 100+ connectors with banks, ERPs, CRMs, payment providers, and accounting suites.

## Peppol & e-invoicing

- [Peppol Access Point overview](https://www.billit.eu/nl-be/peppol-e-invoicing-access-point/): What Peppol is, how it works, and Billit's role as a certified Access Point.
- [Country list](https://www.billit.eu/nl-be/peppol-e-invoicing-access-point/peppol-en-e-invoicing-landenlijst/): Per-country e-invoicing mandates and Peppol coverage.
- [Connect software to the Billit Access Point](https://www.billit.eu/nl-be/peppol-e-invoicing-access-point/koppel-jouw-software-met-het-billit-peppol-access-point/): Integration paths for software vendors and ERP providers.

## Audiences

- [Self-employed and freelancers](https://www.billit.eu/nl-be/voor-wie/zelfstandigen-en-freelancers/): Lightweight invoicing for solo operators.
- [SMEs](https://www.billit.eu/nl-be/voor-wie/kmos/): Multi-user workflows for growing teams.
- [Large enterprises](https://www.billit.eu/nl-be/voor-wie/grote-ondernemingen/): High-volume invoicing, ERP integration, multi-entity setups.
- [Public institutions](https://www.billit.eu/nl-be/voor-wie/openbare-instellingen/): Procurement and Peppol-mandated public-sector flows.
- [Accountants](https://www.billit.eu/nl-be/voor-wie/accountants/): Client portal and the Trusted Billit Advisors program.
- [Software & ERP providers](https://www.billit.eu/nl-be/voor-wie/software-en-erp-dienstverleners/): White-label and Access Point integration.
- [Banks](https://www.billit.eu/nl-be/voor-wie/bankinstellingen/): Embedded invoicing for banking platforms.
- [Partners](https://www.billit.eu/nl-be/voor-wie/partners/): Reseller and referral program.

## Pricing

- [Pricing](https://www.billit.eu/nl-be/prijzen/): Document-based plans from €7.50/month, free 15-day trial, no credit card required, free Peppol connection on every plan.
- [120% tax deductibility (BE)](https://www.billit.eu/nl-be/prijzen/billit-is-120-procent-fiscaal-aftrekbaar/): Belgian tax incentive for e-invoicing software through end of 2027.

## Help & support

- [Help articles](https://www.billit.eu/nl-be/helpartikelen/): Searchable product documentation and how-tos.
- [Get started in 6 steps](https://www.billit.eu/nl-be/functies/aan-de-slag-met-billit-in-6-stappen/): Quickstart guide for new users.
- [Webinars & events](https://www.billit.eu/nl-be/hulp-en-contact/webinars-events/): Live and recorded sessions.
- [Helpcenter Sint-Niklaas](https://www.billit.eu/nl-be/hulp-en-contact/helpcenter-sint-niklaas/): Walk-in support center.
- [Remote assistance](https://www.billit.eu/nl-be/hulp-en-contact/hulp-op-afstand/): Screen-share support sessions.
- [Contact](https://www.billit.eu/nl-be/hulp-en-contact/contact/): Sales and support channels.

## Trust & compliance

- [Compliance and trust](https://www.billit.eu/nl-be/over-ons/conformiteit-en-vertrouwen/): Security, privacy, GDPR posture, Peppol certification.
- [Legal information](https://www.billit.eu/nl-be/juridische-info/): Terms, privacy policy, cookie policy.
- [Customer stories](https://www.billit.eu/nl-be/over-ons/klantverhalen/): Case studies across customer segments.

## Company

- [About Billit](https://www.billit.eu/nl-be/over-ons/): Company background. Founded 2014. HQ: Oktrooiplein 1/302, 9000 Ghent, Belgium. VAT: BE0563846944.
- [Careers](https://www.billit.eu/nl-be/over-ons/werken-bij-billit/): Open roles at Billit.
- [News](https://www.billit.eu/nl-be/resources/nieuws/): Company announcements and product news.
- [Press](https://www.billit.eu/nl-be/resources/in-de-pers/): Media coverage.
- [Brochures](https://www.billit.eu/nl-be/resources/brochure/): Downloadable product brochures.

## App & login

- [Free signup](https://my.billit.eu/Account/Register?country=BE&language=NL): Create a Billit account.
- [Login](https://my.billit.eu/Account/Logon?language=NL&country=BE): Sign in to the Billit web app at my.billit.eu.
- [Sandbox login](https://my.sandbox.billit.be/): Sign in to the sandbox environment for API testing.
- [iOS app](https://apps.apple.com/be/app/billit/id6469793857): Native iOS application.
- [Android app](https://play.google.com/store/apps/details?id=eu.billit.mobile): Native Android application.

## Localized portals

- [English (international)](https://www.billit.eu/en-int/)
- [Dutch (Belgium)](https://www.billit.eu/nl-be/)
- [French (Belgium)](https://www.billit.eu/fr-be/)
- [German (Belgium)](https://www.billit.eu/de-be/)
- [Dutch (Netherlands)](https://www.billit.eu/nl-nl/)
- [German (Germany)](https://www.billit.eu/de-de/)
- [German (Luxembourg)](https://www.billit.eu/de-lu/)
- [French (Luxembourg)](https://www.billit.eu/fr-lu/)

## Optional

- [Blog](https://www.billit.eu/nl-be/resources/blog/): Long-form content on e-invoicing, Peppol, and accounting trends.
- [Trusted Billit Advisors](https://www.billit.eu/nl-be/voor-wie/accountants/trusted-billit-advisors/): Certified-accountant partner program.
- [LinkedIn](https://www.linkedin.com/company/billit/)
- [Facebook](https://www.facebook.com/billit.be.nl)
- [Instagram](https://www.instagram.com/billitbenl/)