Customers

A customer is the anchor record that ties together everything you do for a particular person or organization: invoices, sales orders, quotes, loan agreements, rental agreements, appointments, and unit checkouts all point back to one customer record. Because the customer directory is shared infrastructure, any account with Sales, Inventory, Appointments, or Rentals active can create and manage customers — you don't need the full Sales module just to loan equipment or schedule an appointment.

The customer record holds who — name, contact details, addresses, billing defaults. The activity, tasks, notes, and opportunities that belong to a customer are covered on the Notes, Tasks & Activities and Opportunities & Pipeline pages.

Creating a customer #

New customers are created from Sales → Customers → New Customer (or from the customer picker in any other module's form). The required fields are minimal by design — you can always fill in the rest later.

• Company Name — the business, charity, school or care home you're dealing with. Leave it blank for a private individual.
• First Name and Last Name — the person. First Name is optional when you've filled in a Company Name, and required when you haven't; Last Name is always optional.

You need a Company Name or a First Name — one or the other, not both. Fill in both when you deal with a named person at a business, which is the common case for a trade customer.

Which name does the app show? One derived display name appears everywhere a customer is listed, picked, printed or emailed — the customer list, invoice and quote PDFs, the customer portal header, every dropdown. It is the Company Name when there is one, and the first and last name together otherwise. It's derived, so you never type it: change the company name or a name part and every one of those surfaces follows.

Where a customer arrives as a single name instead — the quick-create "+" on another module's customer picker, a store order import, an API call sending only name — that name is kept as the display name and split on the first space to fill First and Last Name, so the customer still reads correctly on the customer list and record page.

• Email — primary contact email, validated on save.
• Phone — primary phone number.
• Website — URL (validated).
• Notes — free-text internal notes, not customer-visible.
• Payment Terms — default terms applied to new invoices: Due on Receipt, Net 15, Net 30, Net 60, or Net 90. If left blank, invoices don't inherit a due date automatically.
• Price List — an optional price list that overrides the default Product price when this customer is invoiced or quoted. Only active price lists appear in the picker.
• Billing Address — street, city, state, postal code, country. Pre-fills on new invoices and quotes for this customer.
• Shipping Address — separate shipping destination; defaults to the billing address on orders when left blank.
• Segments — assign the customer to one or more manual customer segments (dynamic segments are managed by their own rules).
• Custom fields — any custom fields defined on the Customer entity appear at the bottom of the form. See Custom Fields.

The customer list #

The customer list (Sales → Customers) shows each customer's display name — the company for a company, the person otherwise — followed by first name, last name, email, phone, and city/state, so a company's named contact stays visible next to the company it belongs to. Use the search bar to filter by name, company name, first name or last name — the same filter the API exposes. The Trashed filter reveals soft-deleted customers so you can restore them if needed.

To jump straight to one customer from anywhere in the app, use the global search box at the top of the page instead: it matches name, company name, first and last name, email, and phone, and also returns that customer's orders, invoices, returns, rentals, and loans. See Finding Records.

Customer page tabs #

Open a customer to see its full profile and the related data attached to it:

• Details — all fields from the form, displayed read-only with an Edit button.
• Contacts — named individuals at the company (see Contacts below).
• Opportunities — open and closed deals from the pipeline.
• Checked Out Units — inventory units currently or previously checked out to this customer, across all unit types.
• Change History — a full audit trail of every edit, who made it, and when.

The statement #

A dedicated Statement page (the Statement button in the page header from the customer view) is the document you send when you are chasing payment.

Set the period at the top: an As at date, and optionally a From date — leave From blank for the customer's whole account. The four figures then foot exactly:

Opening Balance + Invoiced − Paid = Balance Due

• Opening Balance — what was owed the day before the period began. Zero when there is no From date.
• Invoiced — billed inside the period.
• Paid — collected inside the period. Money that arrived after the As at date has not arrived yet, which is what lets you reproduce a month-end statement later and get the same answer.
• Balance Due — owed at the end of the period, and the sum of the balances in the invoice list beneath it.

Below the invoices, the balance is aged into the same buckets as the Invoice Aging report — current, 1–30, 31–60, 61–90, 90+ — as at the statement date. That is the row a chase call is made from.

Three buttons in the header take the statement out of the app:

• Email Statement — sends it to the customer, branded as your business, with the PDF attached. The covering note quotes the same balance the attachment shows. Disabled, with the reason, if the customer has no email address or you do not have permission to send documents.
• Download PDF — the same document as a file.
• Print — opens the PDF in the browser for printing.

Save Filter and Load Filter keep a period you use often, the same way the reports do.

Open sales orders are still listed, under Open orders — not yet invoiced, below the figures. They are neither owed nor invoiced, so they are kept clear of the totals and are not on the statement the customer receives.

Contacts #

Each customer can have any number of contacts — the actual people you deal with. Contacts are managed on the Contacts tab of the customer page (or via the API at /api/v1/customer-contacts).

A contact record holds:

• Name — required.
• Title — job title or role.
• Email and Phone.
• Notes — free-text; not customer-visible.

Contacts can be the Checked Out To party for an inventory unit checkout, so you can track exactly which person at a company has a piece of equipment. The Checkouts action on each contact row in the table opens a modal listing every unit that person has or had checked out.

Deleting a contact soft-deletes the record; its checkout history is retained and stays associated with the customer for reporting.

How customers connect to other modules #

The customer record is intentionally lightweight — it stores contact information and billing defaults, then everything else links to it:

• Invoices & Payments — each invoice belongs to a customer and inherits its billing address and payment terms.
• Sales Orders — orders are created for a customer and can be filtered to open orders on the Statement page.
• Quotes — each quote is tied to a customer and optionally a specific contact.
• Opportunities — each opportunity belongs to a customer and a pipeline stage.
• Loan Agreements — free equipment loans record the customer they were issued to.
• Rental Agreements — paid rentals link to a customer for billing.
• Appointments — scheduled appointments are booked against a customer record.

Doing it from the API #

# List customers (paginated at 50, supports ?search= filter)
curl "https://your-domain.com/api/v1/customers" \
  -H "Authorization: Bearer $TOKEN"

# Create a company customer
curl -X POST "https://your-domain.com/api/v1/customers" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"company_name": "Acme Corp", "email": "billing@acme.example", "payment_terms": "net_30"}'

# Create an individual
curl -X POST "https://your-domain.com/api/v1/customers" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"first_name": "Dana", "last_name": "Whitfield"}'

# List contacts for a specific customer
curl "https://your-domain.com/api/v1/customer-contacts?customer_id={customer_id}" \
  -H "Authorization: Bearer $TOKEN"

# Add a contact
curl -X POST "https://your-domain.com/api/v1/customer-contacts" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"customer_id": "{customer_id}", "name": "Jane Smith", "title": "Accounts Payable", "email": "jane@acme.example"}'

At least one of company_name, first_name or name is required on create. name is the read-mostly display name: it comes back on every response and is the company name when there is one, otherwise the person's name. Sending name alone still works and is what older integrations do. The customer_id field in contact requests takes the customer's id. The payment_terms field accepts due_on_receipt, net_15, net_30, net_60, or net_90. DELETE on a customer or contact is a soft delete — all associated transactions are retained.