Skip to main content

Offers, sales and money owed

Four things live together here, in the order money usually moves through them:

  1. an offer (a quote) — what you proposed, and for how much;
  2. a sale — what somebody actually bought;
  3. a payment — money that arrived;
  4. a balance — an instalment still owed.

Each has its own screen, and each of them also appears on the person it belongs to. If you only ever look in one place, look at the contact: their profile carries all four.

Whose ledger is this?

A workspace can decide, per record type, whether its sales live here or in a connected CRM — see Who keeps what in the CRM settings. That answer changes what these screens show, and it is called out under each heading below.

Who can see and do what​

ActionPermission
Read offers, sales, payments and balancescrm.view
Write and answer offersdeals.manage
Delete an offerdeals.delete
Write sales, take payments, void a paymentsales.manage

Somebody with only crm.view sees every screen here and can change nothing on them.

Offers​

An offer is a priced document you send to somebody. Open Offers from the left navigation for every offer in the workspace, or open a person's profile for theirs.

The five answers an offer can be in​

StatusWhat it means
DraftWritten, not sent. Editable; nobody has seen it.
SentOut with the customer, waiting.
AcceptedThey said yes. It can be turned into a sale.
DeclinedThey said no — optionally with a reason you choose from your own list.
ExpiredIts validity date passed without an answer.

The Offers screen opens on Sent, because those are the ones somebody can act on this morning. The other tabs — including All — write themselves into the address, so a link to "declined offers issued in August" is a link you can send to a colleague.

What is on an offer​

Each line names a service or product, how many, the unit price, any discount, and its own total. Every figure comes from the document itself — nothing on the screen multiplies anything, so what you read is what the customer was sent.

A line's name is copied when it is written. Renaming a service in your catalogue later does not rewrite an offer you already sent.

Open a row to see its lines. On a person's profile the lines are simply there.

Editing, revising, answering​

  • A draft can be edited freely.
  • Once sent, it is a document somebody is holding: instead of editing it you revise it, which writes a new version and keeps the old one.
  • Accept or decline it from the offer itself. Declining can record a reason from the list you keep in settings.
  • An accepted offer can be converted into a sale — once. The lines come across with it.

What the filters do​

Search matches the document number and the name of whoever it went to, because the question people arrive with is usually a name. The date range is over the issue date, so a range excludes every draft — a document nobody has sent was not issued in August or in any other month.

There is deliberately no sort by amount: offers can be in different currencies, and ordering 100 USD against 5.000 TRY needs an exchange rate this system will not invent.

At the top, the filter's total is shown one line per currency, over every offer the filter matched — not only the page you can see.

When the CRM keeps the offers

If the connected CRM owns this record type, a list across every customer cannot be asked for at all: that connection can only be asked about one person at a time. The screen says so rather than showing an empty table, and each person's offers appear on their own profile, read live.

Sales​

A sale is what somebody bought. It is draft until you confirm it, and can be cancelled. A confirmed sale gets a document number.

The sale carries its lines and its total; how much has been collected and how much is still outstanding are worked out from the payments against it, never stored as their own number — so they cannot drift apart from the payments they describe.

Payments​

A payment records money that moved. Take one from a person's Debts and payments tab, against a whole sale or against one instalment.

FieldMeaning
WhenThe date the money arrived.
HowCash, card, bank transfer, online, through a third party, or other.
DetailThe bank, the acquirer, the instalment plan — your own words.
ReferenceAnything you need to reconcile against later.

Two rules are worth knowing because they are not the obvious ones:

  • A payment is never deleted, only voided. A payment row is a claim that money moved, and deleting one makes it disappear from a ledger somebody reconciles against a bank statement. A voided payment stays on the list, marked, and stops counting.
  • The currency comes from what is being settled, not from a picker. Money paid in one currency does not settle a debt denominated in another, and the server refuses the mismatch rather than converting it.

A refund is a payment in the other direction. It appears on the same list with a minus sign, not filed away somewhere else.

Money owed​

Open Receivables from the left navigation. This is the chasing list: every instalment still owed, across everybody, oldest first — which is the order you would work it in.

It opens on overdue, because that is what somebody can act on. The other tab shows everything still open. Neither tab shows settled instalments: those are history, and a chasing list of things nobody has to do is a longer list that says less.

You can search by who owes it, bound the list to a due-date range, narrow it to one currency, reorder it, choose your columns, and page through it.

About the numbers​

Late is decided by the server, not by your browser. Two screens working out lateness from a date would eventually disagree — one in your timezone and one in the browser's — and a debt that looks late on one screen and punctual on the next is worse than either answer.

The total is per currency, and it is the whole filter. Adding lira to euro needs a rate nobody here may choose. What is shown is the sum of what is still owed — after everything already collected — over every row the filter matched, not the rows on screen.

"Most owed first" appears once you pick a currency. Across currencies it cannot be answered — ranking 100 USD against 5.000 TRY is the same missing exchange rate that stops this screen printing one figure — so the option is not offered until the list is down to a single currency. Inside one currency the objection disappears, and "who owes us the most" is usually the second question after "who is late".

It ranks by what is still owed, not by what was originally billed: somebody who has already paid nine tenths of a large instalment should not sit above somebody who owes all of a small one.

The currency list keeps offering the other currencies after you pick one, and only offers the ones your other filters can actually reach — picking a currency your search has no rows in would just empty the screen.

When the CRM keeps the ledger

The list still shows the rows a takeover has brought across, with a note saying so. That is deliberate: an empty table under this screen's title would read as "nobody owes you anything", which is a very different sentence from "the answer is over there".

On a person's profile​

A contact's profile has a Debts and payments tab carrying all of it for that one person: what they bought, what is still owed, and every payment they have made — including the cancelled ones, marked, because the statement they are reading down the phone still has them.

Their Offers tab does the same for offers, with the lines.

If the connected CRM keeps the ledger, this tab shows their balance, read live, rather than ours — so the card and the CRM section beside it cannot disagree.

Bringing history over from another system​

If you are moving from another CRM, the takeover brings offers, sales, balances and appointments across in one bounded run. See the CRM settings screen; it is deliberate, metered, and resumable, and it reports what it brought and what it refused, class by class.

Keeping balances current afterwards​

You do not need to run the takeover again to keep money owed up to date. When the CRM's automatic sync is switched on and Sales & payments is set to Both in Who keeps what, every sync pass reads the CRM's whole open-balances list — one request for the whole clinic, not one per patient, and no more often than the sync interval you chose.

  • New debts arrive for people already linked to the CRM. A debt for somebody who has not come across yet is counted and left; the next takeover or appointment sync brings the person, and the pass after that their debt.
  • A debt the CRM no longer lists is closed here — usually because it was paid there. It is marked closed, not paid: the CRM's list does not say whether it was paid or cancelled. If the CRM lists it again, it reopens.
  • A payment taken here is never undone. If money was recorded against an instalment in ConnectWiz, the sync leaves that row exactly as it is, even if the CRM has not heard about the payment yet.
  • It only closes after reading the whole list. A pass that stopped early closes nothing, and a pass that would close more than half of what is open at once closes nothing either and says so — that is what a broken filter over there looks like, and a real clinic rarely collects half its book in an hour.

With Sales & payments set to Here, the sync only brings debts you have never seen and changes nothing that already exists. With Their system, nothing is read: every screen reads the CRM's ledger live.