Estimates

An estimate is a proposed invoice — a quote you send a customer before they commit. Estimates aren't accounting events: they don't post to the GL, don't affect AR, and don't appear on the trial balance. They live in their own table and become real journal entries only when you convert them to invoices.

This page is the deep reference. The Accounts Receivable page has a shorter section that covers the basics in the AR context.

When to use an estimate vs. an invoice

Situation	Use
Customer hasn't agreed yet — you're quoting them a price	Estimate
Customer agreed — work / delivery is happening or has happened	Invoice
Recurring customer who agrees up front to a SOW	Estimate first, convert to invoices as work progresses
Customer asks "what would this cost?"	Estimate
You've already shipped — bill them	Invoice (skip the estimate)

The defining property: estimates are proposed commercial activity, invoices are committed. Estimates exist to give you a sales-pipeline tool without polluting the GL with maybe-revenue.

What an estimate stores

Field	Notes
Estimate number	Auto-generated from a configurable sequence; can override per estimate
Customer	Required; one customer per estimate
Date	When the estimate was prepared
Expiration date	Optional; when the quote stops being valid
Status	Lifecycle marker — see below
Currency + exchange rate	For multi-currency customers
Memo	Notes for the customer
Subtotal, tax, total	Computed from the line items
Conversion link	If converted, points at the resulting invoice

Each line item has:

Field	Notes
Item	Optional; pulls description, price, account from the items list
Description	Free text; defaults to the item's description if an item was picked
Quantity	Decimal — supports fractional quantities
Unit price	In the estimate's currency
Amount	Computed from quantity × unit price
Tax code	Optional per-line tax assignment
Account	The income account this line would post to if converted
Class / Location / Project	Optional dimension assignments (Pro and Accountant tiers)

The line model exactly matches the invoice line model — that's deliberate. Conversion is a 1:1 mapping; an estimate's line becomes the future invoice's line with the same numbers.

Status flow

draft  →  sent  →  accepted  →  converted
                ↘  rejected
                ↘  expired

Status	Meaning
`draft`	Being written. Not yet shown to the customer.
`sent`	Delivered (printed, emailed, handed over). Awaiting customer response.
`accepted`	Customer agreed. Ready to convert when work begins.
`rejected`	Customer declined. Stays in the system as historical record.
`converted`	Converted to an invoice; `converted_to_je_id` points at the invoice
`expired`	Past `expiration_date` with no acceptance

Statuses move in roughly that order, but you can override at any point — recording an estimate as accepted directly without going through sent is fine if the agreement happened over a phone call.

Sending an estimate

Solid prints estimates to PDF. The PDF format is configurable — your logo, your colors, your terms — and matches the invoice template style so customers see consistent documents from you.

Email delivery from inside the app is a future feature; for now, generate the PDF and send via your own email. Customers don't need a Solid Accounting account to read or accept an estimate.

Converting to an invoice

When the customer agrees and you're ready to bill, convert the estimate:

Open the estimate
Click Convert to Invoice
Solid creates a new invoice, pre-populated with every line from the estimate (item, description, quantity, price, account, tax)
Adjust the invoice if needed — change a quantity, add a line, update the date — before posting
Post the invoice as normal: the GL effect is DR AR / CR revenue per line

After conversion:

The estimate's status moves to converted
converted_to_je_id stores the journal entry ID of the resulting invoice
The estimate stays in the file forever — you can see the original quote text alongside the invoice it produced

You can convert the same estimate to multiple invoices over time if the work is staged (e.g. a 3-phase consulting engagement where you bill at the end of each phase). Each conversion produces a new invoice; the estimate's converted_to_je_id updates to the most recent one. The full conversion history is in the audit trail.

Why estimates aren't journal entries

Two reasons:

They might not happen. A quote that gets rejected or expires shouldn't ever have touched revenue or AR. If estimates posted to the GL, you'd need a contra-entry to undo every rejection — noisy and easy to mess up.
They're sales-pipeline data, not accounting data. Pipeline data has different value (forecasting, win-rate analysis, sales reporting) than accounting data. Mixing them into the GL would dilute both.

The trade-off: estimates don't appear on the cash-flow forecast or AR aging until they're converted. If you want forward-looking revenue visibility (committed but not invoiced), use the Open Estimates Report — it's in the reports section under Sales.

Multi-currency estimates

If a customer has a non-base currency, estimates default to that currency. The exchange rate is stored on the estimate at quote time. When you convert to an invoice, the invoice can use either:

The estimate's exchange rate — locks the price in base currency at quote time. Common for fixed-price contracts where you've absorbed FX risk.
The current exchange rate — re-quotes in base currency at conversion time. Common for cost-plus arrangements where FX risk passes to the customer.

Solid asks at conversion time which to use; default is the estimate's rate (the conservative choice for the customer).

Reports

Three estimate-specific reports:

Open Estimates — every estimate in sent or accepted status with totals. The "what could become revenue" view.
Estimate Conversion Report — sent vs. accepted vs. converted vs. rejected — your sales win-rate.
Expired Estimates — estimates past expiration that should be re-quoted or marked rejected.

All three export to PDF and CSV.

Common gotchas

Estimate status stuck on sent even though the customer accepted — status doesn't auto-update from "I emailed it." Mark it accepted when the customer confirms, or just convert directly when work starts (which moves status straight to converted skipping accepted).

Converted to invoice but the customer wants to change the price — the estimate's status is now converted with a fixed conversion record. To change the price: open the resulting invoice and edit it (if not yet posted) or post a credit memo + new invoice for the corrected amount (if posted).

Multiple invoices from one estimate — supported, but the estimate's converted_to_je_id only stores the most recent. If you need a permanent record of which invoices came from which estimate (audit purposes), check the estimate's audit-trail in the activity log.

Expired estimate the customer now wants to accept — re-quote it. Either change the expiration date to today and re-mark as sent, or duplicate the estimate as a new one with a fresh date. The duplicate path is cleaner because it preserves the original quote terms in case of dispute.

Estimate doesn't show on AR aging — correct; estimates aren't AR until converted. AR is what customers owe you — an estimate is a quote, not an obligation.

Cross-references

Accounts Receivable → Estimates — the AR-context summary
Accounts Receivable → Invoicing — what conversion produces
Items module — the items that populate estimate lines