Invoice lines draw straight from the job records the floor already ran against. Quantity produced, consumables used, time spent. No month-end reconciliation.
An invoice has a single, deliberate lifecycle. A draft is the only thing you can edit; issuing is the one-way commit that locks it, numbers it and freezes every snapshot; settlement happens against the locked figure. Correcting an issued invoice means voiding and reissuing, never quietly editing a number someone has already been sent.
Started from one production order. Refine pricing per job, add services or charges, fill custom fields and notes. It carries a DRAFT-NNNNNN placeholder so an abandoned draft never burns a real number.
One transactional commit: re-price every line from live data, run the hard gates, assign the gapless YYYY-INV-NNNNNN number, set the due date, freeze all snapshots and the reporting figure, then render the PDF.
Payments knock the balance down in cash; applied credit notes net the rest.balance = total − paid − credited, recomputed on the server and stamped paid the moment it hits zero.
A line doesn't re-derive a total from quantity times unit price and hope the rounding matches. It takes the agreed value off the job the floor produced (priced by one of four resolvers) and bills it exactly, in integer minor units.
Quantity produced, consumables chargeable, time spent: the same record the floor signed against, no re-keying.
One of four sources sets the line price: the agreed job value, a catalogue service, a rate template, or a manual override with a reason.
Billed verbatim: the line subtotal is the agreed value, not a re-multiplied guess, so there's no rounding drift between floor and finance.
Not settings to configure: rules the system enforces on its own. No burned numbers, no rewritten history, no rounding drift, no double-billing. The books stay clean without anyone policing them.
Real numbers are only spent when an invoice is issued, so the sequence is complete every year. No spreadsheet reconciliation, no awkward questions.
Issuing freezes who was billed, from whom and in what currency. Rename a customer next year. Every invoice you've ever sent stays exactly as sent.
The value agreed on the job is the value on the invoice, never re-multiplied, never rounded. Nothing for a customer to query or finance to chase.
Fixing an invoice voids it and reissues a new one. The old document stays on record and its jobs free up to bill again. Nothing is quietly edited.
Every invoice is in your customer's currency, and jobs that don't match are blocked up front, before they turn into an awkward credit note.
Once a job is on an issued invoice, no other invoice can pick it up. Customers can't be double-billed. The system won't allow it.
A credit note is the accounts-receivable counterpart: a positive-amount document applied to invoices through allocations. Those allocations, not a status flag, are the single source of truth for what's been netted.
A locked, numbered document raised against one production order. It snapshots the agreed job values into priced lines, tracks payment, and carries a live balance the server keeps.
Raised from an issued invoice with server-capped creditable lines, or standalone as goodwill. Its face value splits into applied, refunded and available, and an allocation reduces a specific invoice's balance.
There is no "overdue" column waiting to go stale. Every figure on the AR screen is derived live on the server. The page does no sums, no overdue math, no conversion.
due_date < today, ordered most-overdue first. Nothing to update.It turns finished work into invoices: lines draw straight from the same job records the floor ran against (quantity produced, consumables chargeable, time spent), so nothing chargeable slips through.
No. Because the job already knows what to bill, invoice lines come from the real job records rather than a spreadsheet, so there is no month-end reconciliation and no re-keying.
In a couple of clicks. The job carries what was produced, consumed, and timed, so you raise the invoice from that record rather than re-entering it by hand.
AR is computed, not stored. Status, balance, overdue and conversion are all derived live on the server. There is no "overdue" column waiting to go stale, and the page does no sums of its own.
Cross-currency AR reads a figure frozen at issue, so a later FX edit cannot retroactively move what a customer owed. Balances roll up per customer in the org-global reporting currency, with a live fallback when a rate was missing at issue.
Yes. Credit notes are gated so corrections go through a controlled path rather than being edited freely against an issued invoice.
Bring the spreadsheet you re-key invoices off today. We'll wire it to your real job records and issue a live invoice from the floor. Then you decide.