Skip to main content

Bill-to profiles

Sometimes one customer pays through more than one legal entity. The shops are invoiced to a (Pty) Ltd with its own VAT number, the house is invoiced to the owner personally, and a leased unit is invoiced to the landlord. It is one relationship, one contact history, one set of sites — but the invoices have to be made out to different parties.

A bill-to profile is one of those parties. A customer can hold as many as it needs, and each site, subscription, job or invoice can name which one it bills to.

Most customers never see this

Every customer already has exactly one bill-to profile, created automatically from its own billing details and kept in step with them. While a customer has only one, no picker appears anywhere in CleverOps and everything behaves exactly as it always has. The pickers only appear once you add a second payer.

Where to find them​

Video Bill-to profiles · 0:34

Open a customer, go to the Billing tab, and look for the Bill-to profiles card near the top.

Each profile shows its legal name, and underneath it whichever of the following have been captured: the picker name, VAT number, registration number and billing email. The customer's own payer is marked Default.

Adding a payer​

Video Add a payer · 0:26

Click Add payer and fill in:

FieldWhat it is
Legal nameThe name the invoice is made out in. This is the only required field.
Name in pickersOptional short label, for when two payers have confusingly similar legal names — e.g. "Head office" or "Mr Shaikh personally".
TypeBusiness or Individual. This decides whether the next field asks for a registration number or an ID number.
Registration number / ID numberThe CIPC registration number for a company, or the ID number for a person. The ID number carries its own SA ID / Passport / Other dropdown -- an existing payer captured before that field existed shows Not stated until somebody says.
VAT numberPrints on this payer's tax invoices.
Billing addressPrints in the "Bill to" block.
Accounts contact, Billing email, Billing phoneWhere this payer's invoices and reminders go.
Printed referenceOptional. Useful when a payer is known by an old account code you still want on the document.

Both the registration number and the ID number are kept if you switch the type back and forth, so nothing is lost.

On a customer's default payer, the legal name, entity type, registration number, ID number and its document type are the same fields as on the customer record itself -- edit either and the other follows.

Saying who pays for what​

Once a customer has more than one payer, a Bill to choice appears in four places:

  • On a site — in the customer's Sites & contacts tab, each site row gets a bill-to selector. This is usually all you need: point the leased unit at the landlord and leave the rest alone.
  • On a subscription — overrides the site, for when one recurring service on a site is paid by someone else.
  • On a manual invoice — sits directly under "Issued by", so you can see who issues and who pays together.
  • On a job or quote — carried through to the invoice it becomes.

Every one of these can be left on Customer default. That is not the same as picking the default profile by hand: it means "whoever the default is at the time", so it keeps following the default if you later change it.

What ends up on the invoice​

The Bill to block on the invoice, the customer portal and the statement all show the payer's own legal name, address, contact, VAT number and registration number. The customer's account number stays on the document as well, because that identifies the relationship rather than the payer.

The monthly run​

The monthly billing run produces one invoice per payer. A customer whose shops bill to the company and whose leased unit bills to the landlord gets two invoices in the same run, each carrying only its own lines and its own VAT number.

This happens even when the customer is set to combine invoices, for the same reason a control room with two legal entities gets one invoice per entity: an invoice can only be made out to one party.

The second invoice's description names the payer, so the two are distinguishable at a glance on a statement.

Editing a payer after invoices have gone out​

An invoice records the recipient's details at the moment it was issued, and keeps them.

That means correcting a payer's address or VAT number will not silently rewrite invoices the customer already has — which is what the VAT Act requires of a tax invoice, and what makes an old invoice still match the copy in the customer's own records. Drafts still pick up the new details, because they have not been issued yet.

For the same reason, the bill-to of an invoice can only be changed while it is still a draft. Once it has been issued, correcting who it was made out to means issuing a credit note and raising a new invoice — the same rule that already applies to the issuing entity.

Changing the default​

Use Make default on any active profile. The customer's own billing details follow the new default, so the two never disagree.

The default profile cannot be archived, and the customer always has exactly one.

Archiving a payer​

Use Archive on a payer you no longer invoice. Archiving hides it from the pickers without touching history: old invoices and statements still show it, because they were genuinely made out to it.

If anything still points at the profile, the archive is refused and the message says exactly what — how many sites, active subscriptions, open jobs, open quotes and pending deposits. Point those elsewhere first.

Statements​

A statement can be produced for the whole customer, or for one payer's ledger. The account-wide statement is unchanged and still shows the whole relationship; the per-payer view answers "what does the landlord owe?" without the rest of the account in it.

Accounting sync​

A customer's default payer syncs to your accounting package exactly as it always has, under the customer's existing contact.

A non-default payer is a different legal entity, so it needs its own contact in the ledger. Until that contact exists, invoices billed to it are held rather than pushed — you will see them flagged in the sync log with an explanation. This is deliberate: pushing them under the customer's contact would attribute the money to the wrong debtor in your books, and that cannot be undone from CleverOps. Once a contact exists for the payer and is linked, the held invoices sync on the next run.

See Accounting sync.