The Vehicle Ledger

The Vehicle Ledger is the per-entity financial view that tells the complete money story of a single vehicle repair or job. While the Collection Queue shows what needs attention across the workshop, the Vehicle Ledger answers: for this one vehicle, where does the money stand?

This per-entity view is what makes BayWise Payments different from flat transaction lists. Every vehicle tells its own financial story — what was quoted, what was invoiced, who has paid, who has not, what went to vendors, and what is left.

Balance basis

The ledger computes balances from a basis amount — the total expected revenue for the job. The basis flips automatically based on the entity’s lifecycle:

This flip is automatic. When the workshop moves from estimate to invoice, the ledger recalculates all outstanding amounts against the new basis. No manual adjustment is needed.

The base for all calculations is the total active expected amount — the sum of what the customer and insurer are expected to pay.

Non-insurance jobs

For a standard repair with no insurance involvement, the computation is straightforward:

customerPayable = base amount (invoice or estimate)
collected = sum of all active, non-voided inflow transactions
outstanding = max(0, customerPayable - collected)

Outstanding never goes negative. If a customer overpays, the outstanding shows zero, not a negative balance. Overpayments are handled operationally (refund or credit note), not by allowing negative outstanding.

Insurance jobs

Insurance jobs split the expected amount between the customer and the insurer. BayWise Payments computes this split as follows:

insurancePayable = explicit insurance split amount
                   OR derived: base - expected_customer_amount
customerPayable  = base - insurancePayable

The insurance portion can be set explicitly (the insurer will pay exactly this amount) or derived by subtracting the expected customer amount from the base. Either way, the two portions always sum to the full base amount.

Example: Al Futtaim Auto, Dubai

A collision repair is invoiced at AED 8,500. The insurance assessor confirms a customer excess of AED 1,700.

The customer pays AED 1,700 in cash at vehicle collection. The insurer remits AED 6,800 via bank transfer 30 days later. Both transactions appear in the ledger, each reducing the outstanding of their respective bucket.

If the customer pays first, the ledger shows:

• Customer outstanding: AED 0
• Insurance outstanding: AED 6,800
• Total outstanding: AED 6,800

The job cannot close yet — insurance money is still pending. But the customer’s obligation is fulfilled.

Only active transactions count

The ledger only counts transactions that are:

1. Active — not voided
2. Inflow — direction is inflow (for collected totals)

Voided transactions appear in the ledger view for audit purposes but are excluded from all balance computations. Outflow transactions (vendor payments) are tracked separately and do not affect the customer/insurer outstanding.

Net on job

The ledger provides a net on job figure that shows the workshop’s true financial position on this entity:

Net on Job = Invoice (or Estimate fallback)
           - Collected (all settled inflows)
           - Vendor Paid (settled outflows)
           - AP Pending (unsettled outflows)

This tells the workshop manager: after accounting for everything collected and everything owed to vendors, what is the actual financial outcome of this job? At Tanaka Auto Service in Osaka, the manager reviews net-on-job for completed repairs to assess real profitability after parts costs.

CollectedTotalsCard

At the top of the Vehicle Ledger sits the CollectedTotalsCard — an interactive summary that serves as both a display and an editing surface.

The card shows:

• Invoice amount (or estimate) with reference number — inline-editable
• Collected total (from customer + insurer)
• Outstanding amount
• Insurance split breakdown (for insurance jobs)

Invoice and estimate amounts can be edited directly in the card. Changes save on blur with debounce. Amount validation enforces a range of 0 to 10,000,000 — values outside this range are rejected.

Outstanding computation

Outstanding is always computed as:

outstanding = max(0, payable - collected)

The max(0, ...) floor ensures outstanding never displays a negative value. This applies to both the customer and insurance portions independently:

• Customer outstanding = max(0, customerPayable - customerCollected)
• Insurance outstanding = max(0, insurancePayable - insuranceCollected)
• Total outstanding = customer outstanding + insurance outstanding

Close Job gate

A job can only be closed when customer outstanding equals zero. Accounts payable (what you owe vendors) does not block job closure — vendor payments may settle on longer terms than the customer side.

This means:

• Customer has paid in full (or customer payable is zero) — job can close
• Insurance payment is still pending — job can close (insurance is tracked separately)
• Vendor AP is outstanding — job can close (AP continues independently)

At Sharma Motors in Mumbai, jobs are regularly closed once the customer walks out with the vehicle and pays in full, even if vendor invoices for parts are still on Net-30 terms.

Why per-entity matters

Most workshop management systems track money in flat lists — a table of payments, a table of expenses, disconnected from the work they relate to. BayWise Payments takes a different approach: every financial event is attached to the entity that caused it.

This means the workshop owner can answer questions that flat lists cannot: Did we make money on this job? How much did insurance actually cover? Which repairs have outstanding vendor payments? Is this customer’s balance clear?

The Vehicle Ledger is the surface where those answers become visible.

Related pages

• Entities & Transactions
• The Financial Modal
• The Collection Queue
• Payment Methods