Projects, invoices and operations

Most of a CRM is designed to be permissive. If someone wants to record something unusual, the right answer is usually to let them, because the world is more varied than any model and a system that fights its users loses. Consonas is permissive nearly everywhere, and this part of it deliberately is not.

Financial records are the exception, and the reasoning is worth stating because it explains several decisions on this page that otherwise look inflexible.

A commercial record is not primarily a note of what happened. It is evidence, and it will eventually be read by somebody who was not there: an accountant, an auditor, a customer disputing a charge, occasionally a court. Its value comes entirely from the properties it is guaranteed to have. A sequence with no gaps is useful because there cannot be gaps. A balance derived from recorded payments is useful because it cannot be asserted. The moment either becomes editable, it stops being evidence and becomes someone's account of events.

So in this part of the product, the design refuses. A credit note larger than what remains uncredited is rejected rather than recorded. An invoice number cannot be chosen, and it is allocated at the moment the invoice is sent, so an abandoned draft leaves no gap in the sequence. Where an organisation has asked for approval, an unapproved contract will not send. Each of those is occasionally inconvenient, and each is inconvenient at exactly the moment someone is about to create a problem for their future self.

What is absent

No ledger. No chart of accounts. No bank reconciliation. No VAT return. No payroll. No submission to HM Revenue and Customs. No card processing, direct debit or payment collection of any kind. No billing from recorded time: no rates and no job costing. No recurring invoices today.

Why that is a decision instead of a gap

Payroll and tax filing carry obligations and testing regimes that would take over the product, and doing them adequately is worse than not doing them. Accounting is a mature, well served category where the incumbents are good and the switching costs are high for excellent reasons.

Building a second, worse general ledger inside a CRM is a well documented way for a product to become mediocre at two things. It is on the roadmap under the heading of decisions made rather than work outstanding.

What is here instead, and why

The commercial history as part of the relationship. What was quoted, what was delivered, what was invoiced, what was paid, what was disputed and what was agreed, alongside the conversations and the work, on one timeline.

The reason that is worth having even with an accounting system in place is that the accounting system knows the amounts and nothing about the relationship. It cannot tell you that the invoice under dispute was the one following three service failures, and that is usually the sentence somebody actually needs.

An invoice number is never issued out of sequence

Numbers are allocated in order with no gaps. You cannot choose one, skip one, or reuse one, and a failed attempt does not consume a number that then goes missing.

The reason is that a gap in an invoice sequence is the first thing anybody looks for, and explaining an innocent one to an auditor is considerably more work than never having created it. A system that allows the gap will produce one eventually, usually during the week somebody was in a hurry.

A credit note cannot exceed what remains uncredited

Not the invoice total, what remains. Credit an invoice twice and the second is checked against what is left rather than against the original figure.

This is the arithmetic error that is easiest to make and hardest to notice, because each individual credit note looks entirely reasonable on its own. The refusal costs a moment of irritation once and prevents a reconciliation that takes a day.

A payment cannot settle more than is owed

Overpayments happen and they are a real thing that has to be handled, but they are handled as an overpayment rather than by an invoice quietly going negative.

One person cannot approve their own contract

A contract can be sent for approval, and an organisation that turns the setting on makes it compulsory, after which a draft nobody approved will not send. Whoever asked for the approval is refused by name when they try to give it. In a small organisation this occasionally feels like ceremony, and it is the single control that most reliably prevents the failure mode where one account, compromised or departing, commits the business to something.

It is a protection for the organisation rather than a statement about the person, which is the framing worth having when someone complains about it.

Everything refused says why

A refusal with no explanation is indistinguishable from a fault, and people work around faults. Every one of these tells you what it checked and what would have to be true, so the response is a decision rather than a support message.

An invoice is a header and its lines, and the lines carry copies

The header holds the reference, the customer, the project and the quotation it came from where there was one, the status, the currency, the net, the tax, the total, the amount received so far, the date payment is due, the terms, an owner and the date it was raised. The lines sit underneath it: a name, a quantity, a unit price, a tax rate, and the net and tax that were worked out from those.

The important word is copies. A line does not point at an entry in the catalogue, it carries the price that was actually charged. Change the catalogue price next month and every invoice already raised says what it always said. A document someone is holding must not quietly become a different document, and the only reliable way to guarantee that is to stop the line from referring to anything that can move.

Every amount is a whole number

Money is held in minor units, so one hundred and twenty five pounds fifty is stored as twelve thousand five hundred and fifty. A tax rate is held in hundredths of a per cent, which is what it takes to express five per cent and twelve and a half per cent in the same column without a fraction. A quantity is held in thousandths, so a quarter of something is two hundred and fifty.

None of that is visible on screen, where you type pounds and pence and a percentage. It matters because floating point arithmetic on money produces a total that is a penny out on the third line of someone's invoice, and finding that penny costs an afternoon. Tax is rounded once per line and the totals are the sum of the lines, which is the convention the rest of the world uses and therefore the one that reconciles.

A credit note lives in the same numbered series

It is not a different kind of document filed somewhere else. It sits in the same table as invoices, takes the next number in the same sequence, and holds a pointer to the invoice it corrects so that the two reconcile as a pair. It carries an amount, a reason that is required rather than optional, and no tax line of its own.

It is created already sent, because there is no meaningful draft of a correction: the decision to credit somebody is the act. On the printed document the reason appears as the single line, which is deliberate. A credit note that says only a figure invites the question it exists to answer.

A contract is its text, and the text is the record

A contract holds a reference, a title, the customer, the body, a status, a version number, a pointer to the version it replaces where there is one, the dates it runs between, who asked for approval and when, who gave it and when, when it was sent and to whom, and how the customer answered including the reason if they declined.

Underneath it sit obligations: what either side promised to do, as dated rows rather than as sentences buried in the body. An obligation nobody is reminded of is one that gets missed, and the miss is usually discovered by the other side rather than by you.

A project is the work, held against the customer it is for

A project holds a name, the customer, the opportunity it came from where it came from one, a state, the dates it starts and is due, a budget, a currency and an owner. Under it sit phases in order, each with its own due date and a date it was completed. Tasks attach to it. Invoices raised against it are listed on it. The people who did the work are on it with the period they were on it for, and correspondence filed against it is read from it. Risks, issues and decisions can be pinned to it in the register.

What a project deliberately does not hold is a dependency graph, a critical path or a resource plan. It exists because a sale is a promise and somebody has to keep it, not because we intend to compete with the tools built for planning complicated work.

An invoice credited more than once

Each credit note is checked against what remains uncredited, not against the invoice total. Two credit notes that are individually reasonable and jointly larger than the invoice are refused at the second one.

Someone tries to credit a credit note

Refused. A document that corrects a correction reconciles to nothing and consumes a number in the sequence for no reason. If the credit was wrong, the answer is a new invoice, which is a normal document that says what it is.

Money arrives against a credit note

Also refused. A credit note is money owed back rather than money owed to you. It shares a table with invoices, which means that without an explicit refusal its zero received and its positive total look exactly like an unpaid invoice, and a payment against it would quietly mark it settled. The screen never offers the option; the engine refuses it anyway, because the screen is not where a rule of this kind should live.

The customer pays more than they owe

The payment is refused rather than absorbed. Money arriving that does not belong to this invoice is a question for a person, and an invoice that has quietly gone past settled is a question no one will think to ask. In practice the surplus is someone's error, a payment meant for another invoice, or a deposit, and each of those wants a different answer.

An invoice that was never sent turns out to be wrong

A draft cannot be credited, because a credit note against a document no one ever received is a correction to nothing. A draft was never a statement to anyone, so deleting it is the honest answer and no number is consumed by it.

A contract is changed after it has been approved

The approval is cleared and the contract goes back to needing one. What was approved is no longer what would be sent, so the approval no longer speaks for it. A rejected contract returns to draft with the approval fields empty, because a rejection is an instruction to change something rather than a permanent verdict.

The customer answers the same contract twice

The first answer stands and the second is refused. A document with two answers on it is one nobody can act on, and the question of which came first is exactly the question you do not want to be arguing about.

A new version is drafted and then abandoned

The old contract carries on standing. A replacement supersedes what it replaces at the moment it is sent to the customer, not when it is drafted and not when it is approved, because until the customer has seen it the earlier version is still the agreement.

The person named on an invoice asks to be forgotten

The invoice stays and stops pointing at them. Records about a person are removed: consent, timeline, portal account, audience membership. The organisation's own records that happen to name a person are detached instead, because destroying an accounting record on request would breach the retention obligation that sits underneath the erasure obligation, which for a company is the duty to keep accounting records in the Companies Act 2006. Contracts, projects and quotations are treated the same way.

Two currencies at once

What is owed is reported per currency and never added together. A single figure made by adding pounds to euros is not an amount of anything, and a number that cannot be spent is worse than no number because someone will put it in a board pack.

The customer is a supplier as well

They are one record either way. A supplier is a relationship rather than a separate species of contact, so the same organisation you buy from and sell to has one address, one set of people and one history, with contracts on both sides of the relationship held the same way.

Four of the things on this page are optional modules

Projects, invoicing, contracts and suppliers are modules bought per organisation rather than capabilities a plan hands you. They are available from the Standard plan upwards. Quotations, which sit immediately before invoices in the sequence, are a plan feature from Standard instead of a module, which is an inconsistency with an honest cause: one area of the product contains three things that are priced differently.

When a module has not been bought, the answer says the module is not included rather than that you lack permission. Confusing those two sends an administrator hunting through role settings for something that was never a role problem, and that hunt is half an hour no one gets back.

The permissions are split where the jobs are split

Viewing invoices and managing them are separate. Recording money received is separate again, and deliberately so: the person who raises the invoices and the person who reconciles the bank are often different people on purpose, and in an organisation of this size that separation is one of the few internal controls available at no cost.

Contracts split the same way, with approving held apart from managing. The engine refuses self approval by name whatever the permissions say, and the permission decides who is eligible to be the second pair of eyes at all. Projects split into viewing and managing.

What the starting roles actually hold

The administrator role holds all of it across every record. The standard role reads every invoice but cannot raise one, cannot send one and cannot record a payment; it manages the projects and contracts it owns and cannot approve a contract. The restricted role has none of this at all, which is the correct starting point for someone hired last week. The read only role sees projects, invoices and contracts and changes nothing.

Each grant carries a scope of its own, its team's or everything, so the sentence a role makes is closer to who may do what to whose records than to who may do what. Records marked sensitive are excluded from the ordinary scopes, and a project or an invoice inherits sensitivity from the customer or the opportunity it came from rather than needing to be marked again.

What no plan and no module can take away

The audit trail records every change to a financial record with who and when, on every plan including the free one, and no one can edit it including us. The complete export of your data is on every plan permanently. Two factor sign in, consent records and subject access tooling are the same. None of those is a paid upgrade and none of them ever will be, because obligations are not a product tier.

The uncomfortable half is the ordinary one. Buying the module gives the organisation the capability and gives nobody the permission, and an organisation that makes everybody an administrator on the first afternoon has bought none of the separations described above. The product can offer the control. It cannot make anybody take it.

The trades where delivery and billing are the same argument

Projects and invoices are worth most where work is sold before it is done. Construction keeps what was quoted and what was finally invoiced against the same job, consultancy invoices work that was scoped months earlier, professional services holds engagement terms that a second person should have read, and marketing agencies deliver against a retainer that has to reconcile at the end of the month. Each of those pages describes the shape the records take.