Brands
Overview
A brand is one public face under a shared roof: its own legal name, its own logo, its own colours in outgoing communication. If you trade under a single name, one brand is enough and this page barely concerns you.
Brands are more than appearance. They are also the dividing line in the data: documents and work items belong to a brand, and permissions take effect per brand. Master data such as customers and products, by contrast, is brand-neutral — it is not maintained twice.
Core tasks
Create a brand. New brand requires a name and a slug. The slug is the technical short form and should not be changed after creation — it surfaces in places that cannot all be carried along.
Maintain the legal details. The legal name is the full company name for the imprint and the footer of outgoing mail. It is inserted through a placeholder rather than repeated in every template — which turns a change of company name into a single edit.
Set the appearance. Logos and a colour scheme for communication belong to the brand. Both take effect in mail layouts and document templates.
Maintain the brand's standard texts. Header and footer texts for quote, order, invoice and delivery note live as text blocks for documents under document templates. A block with a brand selected and Default set is inserted automatically into new documents of that brand — so each brand carries its own standard texts without copying a template per brand.
Own domain per brand. Under Domains you enter the addresses the brand appears under — such as app.brand.com for the staff application and customers.brand.com for the customer portal (one domain may serve both). Anyone opening one of these addresses sees the sign-in page before signing in already in the brand's look: logo, name, colour. After sign-in Octibiz suggests the brand as the active brand — provided you hold permissions there; which data you see is still decided by your permissions, not by the address. An address that belongs to no brand shows the neutral look. Operations set up DNS and the certificate so the address is reachable.
Customer portal under the brand domain. A portal account whose brand has its own portal domain signs in there (or at the general portal address) — on the portal domain of another brand the sign-in is rejected with the same message as wrong credentials. Links in portal mails (invitation, sign-in link, forgotten password) lead to the portal domain of the account's own brand.
Staff mails under the brand domain. Staff mails link to the brand's app domain: notifications (including the daily digest), assignments of tasks and tickets, alerts from automations, a project's autopilot report and the host mail of an appointment lead to the app domain of the brand of the record concerned. A staff member's invitation leads to the app domain of the brand of their membership. If the brand has no app domain, the record has no brand, or the staff member holds cross-brand access or access to several brands, the main address stays. Separate sign-in per domain: anyone who was only signed in at the main address signs in once more after the first click on the brand domain — the session applies per address.
Deactivate a brand. The active state takes a brand out of day-to-day operation without touching its history. A deleted brand releases its domains.
Fields in detail
The What it does column answers what changes in the system — not what the field is called. The grey name behind the label is the API field: the same thing runs under that name through automation, import and AI tools.
A brand is more than a logo: it is the sender identity and at the same time a visibility cut. Documents, customers and cases belong to a brand, and whoever cannot see the brand cannot see them.
Creating and editing a brand
| Field | Required | Values / format | What it does |
|---|---|---|---|
Slug slug | yes | text, max. 100 characters | The brand's identifier in addresses, number ranges and links. Do not change it once documents exist. |
Name name | yes | text, max. 255 characters | The display name in the interface and in selections. |
Legal name legalName | no | text, max. 255 characters | The full legal designation. Precisely this belongs on invoices — the brand "Example" trades as "Example Ltd", and the legal name must appear on the document. |
VAT ID vatId | no | text, max. 50 characters | The brand's VAT identification number. Once stored it appears on every document and in every e-invoice — where it is mandatory. |
Tax number taxNumber | no | text, max. 50 characters | The tax office number — the alternative for anyone without a VAT ID, small businesses under § 19 UStG for instance. At least one of the two must be present, otherwise the e-invoice check rejects the document. |
VAT rule taxMode | no | standard or small business (§ 19 UStG) | As a small business, every new quote, order and invoice of this brand is created without VAT and with the mandatory § 19 UStG notice. The rule stays editable on each document. |
Email email | no | address, max. 255 characters | Sender and reply address for everything going out under this brand. |
Phone phone / Website website | no | text, max. 50 or 255 characters | Contact details on documents and in signatures. |
Bank bankName, IBAN bankIban, BIC bankBic | no | text | The bank details on this brand's invoices. Two brands can have different accounts — which is exactly why these fields live here and not globally. |
Address addressStreet, addressZip, addressCity, addressCountry | no | street, postal code, town, country as two-letter ISO code (e.g. CH) | The brand's address in the letterhead — and the payee in the Swiss QR bill payment part. Postal code, town and country are mandatory for the QR payment part. |
Holiday region holidayRegion | no | region code of the holiday calendar, e.g. DE-BY; empty = country only | Which holidays apply to the brand in addition to its country. Wherever the system counts working days of the brand — such as the expected delivery date on quotes and orders — the holidays of the country and of this region are skipped. The region brings its country along (DE-BY also counts the nationwide holidays from DE). You maintain the calendars themselves under HR → Holidays; without an active calendar for the region only the country counts. Stored in upper case. |
QR-IBAN qrIban | no | IBAN from Switzerland or Liechtenstein with institution ID 30000–31999; spaces allowed | The account for Swiss QR bills with a QR reference. A regular IBAN is rejected here — it belongs in the IBAN field; without a QR-IBAN the payment part uses a Swiss IBAN from the bank details and a SCOR reference. |
Bank customer number qrBankCustomerNumber | no | digits only, at most 12; spaces allowed | Some Swiss banks require their customer number at the start of the QR reference. If stored, every QR reference starts with it, followed by the document reference and the check digit. Applies to the QR-IBAN only; a SCOR reference stays unchanged. The payment matching assigns incoming payments carrying this reference to the invoice. The reference is stored on the invoice when it is finalised: a later change only applies to invoices finalised afterwards; older ones keep their printed reference and are still matched. |
QR payment part on invoices qrBillEnabled | no | yes/no | Switches on receipt and payment part per Swiss standard. It appears on invoices in CHF or EUR whose document template contains the block "Swiss QR bill payment part". It can only be switched on with an account in Switzerland or Liechtenstein and with postal code, town and country — otherwise saving is refused with a message. |
Language defaultLocale | no | language code, max. 5 characters | The language documents and mails of this brand are produced in when the recipient has none of their own. |
Colours primaryColor, secondaryColor, accentColor, textColor, backgroundColor | no | colour values | The appearance in documents, mails and the portal. |
Default isDefault | no | yes/no | Which brand is proposed when none is chosen. Exactly one; the mark moves. |
Domains domains | no | list of domain (host) and use Staff (app) and/or Customer portal (portal); at most 20 | At these addresses the sign-in page appears in the brand's look beforehand, and the brand is suggested after sign-in. You may paste a whole address — only the host name is stored, in lower case (https://App.Brand.com/login becomes app.brand.com). Every domain belongs to exactly one brand, including its variant with or without www.; an IP address is not a domain. |
Active active | no | yes/no | Off means no new cases under this brand. Existing ones remain complete — a brand is retired, not deleted. |
Settings & permissions
- Permission
platform.brand.manage. Without it the page is unreachable. It applies per brand:
whoever holds it only for brand A maintains only brand A — master data, logos, domains, deletion.
- Permissions take effect per brand. An account sees the data of the brands in which it holds
the relevant permission. What counts is the permission, not mere membership — somebody who has some membership in brand B but no read permission there sees nothing there.
- Brand-neutral master data. Customers, contacts and products apply across all brands. What
belongs to the brand are documents, work items and the public face.
- The brand picker in lists shows only brands you are entitled to. With exactly one brand it
disappears.
FAQ & troubleshooting
A document carries the wrong brand. The brand is set on creation. Moving it afterwards requires the corresponding permission in the target brand, not only in the original one.
Colleagues cannot see the brand. Then they lack the permission in that brand. Membership alone is not enough.
The slug is misspelled. Create a new brand and deactivate the old one rather than changing the slug.
The sign-in page under the brand domain looks neutral. Then the address is not entered on any active brand, it is marked for the customer portal only (instead of the staff application), or the server sees a different host name because of an upstream proxy — a question for operations.
A customer can no longer get into the portal. If they sign in on the portal domain of another brand, they are rejected. The right place is the portal domain of their brand — the link in their portal mails leads there.
The company name in the mail footer is wrong. It comes from the brand's legal name, not from the template. Change it here.