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

# Customers

## What a customer is

A customer is the entity you bill for your products or services. Every invoice, contract, entitlement, and payment in Zenskar is associated with a customer record. You must add a customer before you can automate any billing for them.

## Customer record structure

A customer record has several components:

| Component            | Description                                                                                                                                          |
| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| Customer information | Name, external ID, email, and phone number.                                                                                                          |
| Business entity      | The Zenskar business entity that invoices this customer.                                                                                             |
| Billing address      | The address used on invoices.                                                                                                                        |
| Shipping address     | Defaults to the billing address unless overridden.                                                                                                   |
| Tax information      | Tax IDs and exemption status, used for tax calculation and compliance.                                                                               |
| Custom attributes    | Additional properties defined at the account level and applied consistently across all customers. See [custom attributes](#custom-attributes) below. |
| Contacts             | Additional people associated with the customer, each with their own communication preferences. See [contacts](#contacts) below.                      |
| Wallet               | A per-currency credit balance the customer can use to offset invoice amounts.                                                                        |

<Card title="Customer record structure: reference" icon="table-list" href="/docs/20240301/product-modules/customers/reference/customers">
  See the field-by-field reference for each component of a customer record, including which fields are required.
</Card>

The name is the only required field. External ID and email must each be unique within your organization, so they can double as lookup keys when you're matching a Zenskar customer against a record in an external system.

## Business entity

Each customer belongs to one business entity, the Zenskar legal entity that issues their invoices. If your organization has more than one business entity, you choose which one a customer belongs to when you create the customer.

The dashboard does not let you change a customer's business entity after creation. This restriction is enforced in the dashboard's edit form; it is not a hard limit on the customer record itself.

## Tax information

Zenskar supports tax ID entry for a wide range of jurisdictions, each mapped to the correct tax ID type for that jurisdiction, for example GST for India and Singapore, VAT for the European Union, and TIN for the United States. Select the country and Zenskar shows the right tax ID field for it.

Marking a customer as exempt from tax entirely isn't a standard field on the customer form. It only appears if your organization has defined an exempt tax custom attribute, under **Settings → Custom attributes → Customers**. If you don't see it, add that custom attribute first. See [custom attributes](#custom-attributes) below.

## Custom attributes

Custom attributes are account-level properties you define once, under **Settings → Custom attributes → Customers**, and they then appear as fields on every customer record. This lets you attach structured metadata, such as transaction type, account tier, or segment, to all customers consistently, rather than using ad-hoc data.

Each custom attribute has:

| Field           | Description                                                                          |
| --------------- | ------------------------------------------------------------------------------------ |
| Key name        | The machine-readable identifier.                                                     |
| Display name    | The label shown in the UI.                                                           |
| Data type       | The type of value accepted, for example text, number, true/false, a list, or a date. |
| Default value   | The value pre-filled when creating a new customer if the field is left blank.        |
| Required        | Whether the field must be filled before a customer can be saved.                     |
| Business entity | Which business entities this attribute applies to, or all of them.                   |

## Contacts

A customer has one email address on the customer record itself, and can also have any number of additional contacts. Each contact can be independently set to receive invoice communications. The contact model also supports a separate setting for contract communications, but that one isn't exposed as a control in the dashboard today, it exists in the data model without a way to turn it on from the UI.

## Wallet

Each customer can hold one wallet per currency. A wallet stores credits that reduce the amount due on an invoice. Credits are applied when an invoice is approved, unless wallet application has been turned off for that specific invoice. Credits can be added to a customer's wallet for promotional purposes, or deducted to settle a balance.

<Note>
  The wallet tab is only available for organizations on the earlier contract experience. If your organization has the newer Contracts V3 experience turned on, wallets aren't available on the customer page.
</Note>

## Consolidated billing across related customers

Zenskar supports two related but distinct ways of connecting customers for billing purposes, and it's worth keeping them separate.

Designating one customer as a child of another lets you redirect billing: the child customer still generates its own invoice for its own usage, but that invoice is billed to, and paid by, the parent customer. Nothing is merged, each child keeps its own separate invoice, just addressed to the parent.

<Note>
  The "Add as a child" toggle that sets this up is only available for organizations on the earlier contract experience. If your organization has the newer Contracts V3 experience turned on, this toggle isn't shown on the customer form.
</Note>

Separately, if several customers' invoices need to appear as a single document, you can manually consolidate multiple already-generated invoices from linked customers into one invoice. This is a distinct action taken from the invoice list, not something that happens automatically from designating a parent and child.

## Deletion

You cannot delete a customer while any contract still references them; you must remove the customer from every contract first. Deleting a customer soft-deletes the record rather than erasing it permanently.