Project Profitability Is Decided at Intake, Not at Invoice.

Ask a consultancy or an agency which of last quarter's projects made money and you get a pause, then a story about the one that obviously did not. The firm knows its revenue, its payroll and its utilisation to one decimal place, and it still cannot say which work was profitable, because the answer arrives at the invoice, months after the decision that determined it. That decision was made at intake. Not the pricing; the shape. Whether the proposal wrote its hours, rates and scope in a form the project and the invoice could read, or in prose that two people would re-key.

This video is the intake shape, and what it makes visible from the first week. Everything on screen is a mock demo with sample data: a mock Zoho CRM deal, a mock Zoho Projects project, a mock Zoho Books invoice. Here are two proposals for the same project, a sixty-day systems rollout. The first is prose: discovery, configuration, training and go-live support, one fee, a paragraph each. It is a good document, and it is unreadable to every system that comes after it. The project manager reads it and writes a plan from scratch; the finance team reads it and writes an invoice from scratch; neither plan nor invoice can be compared to it.

The second says the same thing as lines: discovery, forty hours at one rate; configuration, one hundred and twenty hours; training, twenty-four; go-live support, forty. Same scope, same fee. But each line is a record: a sold quantity, a rate, a name. That is the whole difference, and it is decided before the client signs. With the lines in the sales system, the project is created from them, not beside them. When the deal closes, the project record is created with the same four lines as its structure: a task list per line, each carrying the sold hours as its budget.

Nobody re-keys. The project manager refines the plan beneath those lines, and when the plan adds up to more than the sold hours on a line, that is visible on the day the plan is written, which is the first gap: sold against planned, the scope given away in the estimate. In the Zoho suite that is a Zoho Projects project created from the Zoho CRM deal with the quote lines as its task lists; the mechanism is standard and the decision is only that the lines and the task lists are the same four names.

Now the hours. Every time entry is made against one of those four lines, because the task lists are the only places an hour can go. No project-general bucket, no other, and a home for the work that is not client work, so the firm's own time is honest too. The entry carries the person, the date, the hours and the line, which is exactly the shape the invoice will need, and nothing more, which is why people fill it in. This is where the second gap becomes visible as it happens: planned against delivered.

When configuration has consumed one hundred and ten of its one hundred and twenty hours with half the work left, the project manager knows in week five, not in the month-end reconstruction. The time-tracking piece on the site goes into the entry's shape; the rule here is just that the line on the entry is the line on the proposal. The invoice is the last reader, not the first author. For a time-and-materials project it is built from the entries, grouped by line, at the line's rate: discovery, thirty-eight hours; configuration, one hundred and twenty-two.

For a fixed-fee project it bills the fee, and the entries sit beside it as the cost of earning it. Either way the invoice is generated from the same records, never typed, which is the third gap made visible: delivered against billed, the work done and never invoiced. In Zoho Books that is an invoice raised from the approved project time at the line rates; the accounting system owns the billed hours and reads the delivered ones, and no one reconciles two typed documents at month end. Put the three gaps side by side and that is project profitability, visible per project from the first week rather than reconstructed at the end.

Sold against planned is the scope you gave away in the estimate. Planned against delivered is the work the plan did not foresee. Delivered against billed is the work you did and never invoiced. Each one is a number on the project record, because each one is a difference between two records that share a line name. And the next proposal is priced from this project's actuals rather than from the rate card and hope, because the actuals are in the same shape as the lines. That is what decided at intake means: not that the margin is fixed when the proposal is written, but that it can be known at all.

Write the proposal as lines. Create the project from the lines. Code every hour to a line. Build the invoice from the hours. The margin is then a number the system holds from week one, and the next proposal is priced from the last one's truth. The month-end piece on this channel shows what happens when none of that is done; this is the version where it is. We are CodeStringers, a services firm ourselves, and this is how our own projects are run. Discovery is no-risk: we take one of your recent proposals and show what its lines would have made visible.

The links are below.