Skip to main content

Customers

A tenant is a site. A customer is who pays.

Vodia Billing 201

A PBX tenant is a technical object: one domain, on one PBX, with its own extensions and trunks. The party that receives the invoice is often the same thing — but not always. One paying customer can be a handful of sites spread across two PBXs, or an entire PBX, or several entire PBXs for one enterprise.

The customer is the billing unit. Invoices, tax, terms, delivery and the accounting binding all belong to it. Rating belongs to the site.

Every tenant has a customer​

There is no ungrouped state. When a tenant is discovered it is given a customer containing only itself — a group of one — so there is always exactly one billable party and one code path.

For an estate that never groups anything, this changes nothing at all. A group of one produces the same invoice, with the same layout and the same totals, as a per-tenant invoice did.

Asking which customer a site bills under is a stored field, never a rule evaluated at billing time. A computed billing identity is one you have to re-derive months later to explain an invoice.

What belongs to the customer, and what stays on the site​

The rule is one sentence: anything that is a charge stays on the site, anything that is a property of the document moves to the customer.

CustomerSite
CurrencyRate plans, sell and cost
Tax profile, components and registrationInclusion allowances
Account referenceTrunks, DIDs, entity snapshots
Billing email recipientsServices and hardware
Accounting connection and bindingDiscounts and credits
Invoice template and languageRecurring charge generation
Reminder overridesCall rating and rate classes
Payment terms
Online payment (Stripe)

Allowances stay per site deliberately. Grouping is an invoicing change, not a rating change: a site consumes minutes, and its allowance describes what it consumed.

One invoice, one section per site​

A customer receives one invoice covering every member. Each site appears as its own section with its own lines and its own subtotal, so a multi-site customer can still see what each branch cost.

Tax, discounts, credits and the total are computed once, for the customer, on the concatenation of every member's lines.

A group of one has a single member, so no section headings are printed and the document is identical to what a per-tenant invoice produced.

Creating and changing membership​

Customers → New creates a party. Sites are added to it from the member picker.

Three refusals apply at the moment you add a member, rather than at billing time when it would be too late:

  • A customer cannot span currencies. One document, one currency.
  • A customer cannot span tax jurisdictions. One document, one tax computation.
  • A whole PBX is never joined silently. Discover can propose that every site on a system belongs to one enterprise, but it raises a proposal for confirmation and never acts on it.

Emptying a group of one deletes it if it never issued anything. If it did, it is marked inactive and kept, because its invoice numbers are allocated and its documents are somebody's records.

Moving a site between customers​

Issued invoices are never re-homed. An invoice stays with the customer that issued it and keeps the list of members it was built from, which is how a site that moves is still answerable for the months it has already been billed for.

The practical consequence: a late CDR for a closed period is found and carried forward correctly even after the site changes hands.

Billing a customer​

A bill run selects customers three ways:

  • All customers
  • By PBX — every customer with a site on the selected system. An enterprise spanning two boxes is billed in full from either one, and the run names the members that were outside your selection but billed anyway
  • By named customer

A single site of a multi-member customer cannot be invoiced on its own. The draft and finalize buttons refuse it and name the customer, because a second document over the same charges would leave both totals internally consistent and one of them wrong.

If you are holding a draft cut before the site was grouped, delete it — drafts are deleted, not voided — and bill the customer instead.

Blocked members​

One blocked member blocks the whole customer's invoice. This is deliberate: excluding the blocked site and issuing the rest would under-bill silently, and nothing downstream would say so.

The run names the member and the guard, so the one unreviewed trunk holding up a forty-site enterprise can be found.

An inactive member is different: it is excluded from the invoice, and any charges it holds are counted and reported as stranded on the run rather than being quietly dropped.

The accounting binding​

The binding to Xero or QuickBooks lives on the customer, not on any site.

It is resolved from the customer's own binding only, and is never inherited from a PBX. A customer can span two systems, so "the system default" has no single answer.

See Accounting.

The name on the document​

customer_name is stamped onto an invoice when the draft is created and is never refreshed afterwards. An issued invoice keeps the name it was issued under, even after the customer is renamed.

For the same reason the biller export carries both customer_name and customer_id: the name is what a person reconciling reads, the id is what survives a rename. See Export and Delivery.

Worked example​

Voipmart Wholesale is eleven sites across one PBX, billed on one document:

Invoice INV-00750   Voipmart Wholesale   2026-09

Aetox 63.00
CTS & SIP 0.00
Digital Techniques 97.00
Greenbay 8.00
MCIT 16.00
NuLink Test 16.00
Peninsula Tokyo PTK 600.00
snom Australia 24.00
Stav Comm 49.00
Vodia 403.00
Vytec 40.00
---------
Subtotal 1,316.00
Promo15 (15%) — MCIT -2.40
Promo20 (20%) — PTK -120.00
After discount 1,193.60
Tax 62.66
911 fee (39 x 1.00) 39.00
Total 1,295.26
Credit — Outage -35.00
Credit — outage -45.00
Amount due 1,215.26

CTS & SIP is a member with no charges this period. Its section is printed at zero rather than omitted, so the document accounts for every site the customer has.

Each discount and each credit appears once, against the member that earned it, rather than being repeated on every section.

The per-unit 911 fee counts every billable entity across all eleven sites, because the tax computation belongs to the customer.