Sent on the day it was raised. Nothing outstanding.
That is one of three answers
Three questions about one invoice. None of them answers another.
Issuance
Has it been issued?
Issued
The question most software stops at, and the only one it usually asks.
Settlement
Has it been paid?
Part settled
Payments are recorded against the invoice, so part of it can be true.
Delivery
Did it reach anybody?
Never delivered
Kept as its own dimension rather than folded into status, so a bounced invoice cannot read as an unpaid one.
All three are true of the same invoice at the same time. Folding delivery into status would make this one read as unpaid, and somebody would chase a client who never received it.
Look along one axis at a time.
Invoicing
Issued is one dimension of three
One dimension read. Issued. Does that mean the client has it, and has paid?
Status, settlement and delivery are three independent dimensions in Mudo, not one field. The state names are the application’s own. No amount, invoice number, client or date is real.
In short
AvailableAvailable now to practices on a qualifying plan.- What it is
- Practice invoicing built on the project fee structure: claims against stages, agreed variations included, and a practice-wide view of what is outstanding.
- Who it is for
- Practices assembling invoices at month end from a fee spreadsheet, a programme, and a memory of what was agreed on site.
- What is different
- The invoice is raised against the fee structure the client accepted, not against a separate list maintained in parallel. The claim and the agreement are the same record.
- Availability
- Available on every plan, including the free Starter tier.
- How it connects
- Invoicing consumes fee stages and variations, which originate in the accepted fee proposal and move with the programme.
Part of Money.
Verified against the Mudo application on .
Invoicing against what was agreed
The invoice a practice sends should be traceable to the proposal the client signed. In practice it is often traceable to a spreadsheet that was traceable to the proposal, eighteen months ago, before two variations.
Mudo removes the intermediate copy. The fee structure created by the accepted proposal is the structure invoices are raised against.
Variations, claimed rather than remembered
The most common uninvoiced money in a small practice is variation work that everyone agreed to and nobody billed.
Recording a variation as a commercial fact when it is agreed, rather than as a note to handle later, is the whole fix.
Common questions
How does architectural invoicing differ from ordinary invoicing?
Architectural fees are usually claimed in stages tied to events: a stage completing, a set being issued, an approval being lodged. The invoice is therefore an assertion that something happened, not simply that time passed, and the practice needs to be able to show what.
Does invoicing include variations?
Yes. Because variations are recorded against the fee structure when they are agreed, they are available to claim rather than remembered at the end of a job, which is where most uninvoiced variations are lost.
Does this replace my accounting package?
No. Mudo raises and tracks the practice's claims against its projects. Your accounting system remains the financial record of the business.
What this page is based on
Every capability described here was checked against the running application before publication. These are the parts of it you can open for yourself.
- /finance/invoicesThe invoices screen in the application.
Stop discovering an unpaid invoice was never delivered.
Free for solo practices: one user, two projects, no card.