A software company in Kathmandu runs five client projects at once: a banking portal on a fixed price, a retainer for an Australian client, a subcontract on a government system, a mobile app for a local retailer, and an internal product the founders believe in. The company as a whole is profitable - the annual P&L says so. But ask the obvious next question - which of these five projects is making the money and which is losing it - and the room goes quiet. The accounts were never built to answer it.
Project accounting Nepal service firms need closes exactly that gap. It treats each project as its own small business inside the company: with its own revenue, its own costs, its own budget, and its own margin. The company-level P&L then becomes what it should have been all along - the sum of project stories you can actually read - instead of a single blended number that hides a loss-making engagement behind two profitable ones.
This article covers the working parts: setting up project budgets, allocating people and costs to projects honestly, billing against milestones, and the profitability analysis that changes which clients a firm chases next year. The examples follow that five-project IT company, but the same mechanics apply to consulting practices, engineering consultancies, architecture studios, and any business that sells expertise by the engagement.
What Project Accounting Means for a Service Business
In a trading company, the unit of profit is a product; in a service company, it is a project. Project accounting simply makes the books follow that reality: every invoice, every expense, and every hour of staff time carries a project code, so revenue and cost accumulate against the engagement that caused them. The discipline sounds mechanical, but its output is strategic - a project-wise P&L that shows what each engagement earned, what it consumed, and what remained.
Without it, service firms navigate on two misleading instruments. The first is the company P&L, which averages everything: a 45% margin on one project and a loss on another read as a comfortable 15% blend, and the loss is never confronted. The second is cash, which is worse - a project can feel healthy for months because the advance came in, while the hours quietly consumed have already destroyed its margin. In our experience, most Nepali service firms have never seen their own project-wise numbers, and the first honest report is always a surprise: the prestigious anchor client near break-even, the small unglamorous engagement carrying the year.
The prerequisite is structural, not heroic: a project master where every engagement is registered, project codes applied on every transaction at entry, and a rule that nothing - not a taxi fare, not a server bill, not a developer's month - lands in the books without answering "for which project?" Everything else in this article builds on that habit.
A service company's real P&L is the sum of its project P&Ls. Code every transaction to a project at entry, and the blended company number resolves into engagement-level truth - including the loss-maker the averages were hiding.
Project Budgets - The Plan Each Engagement Is Measured Against
A project budget is the engagement's business case written in numbers before work begins. On the revenue side: the contract value, the billing structure, and the expected invoicing schedule. On the cost side: the people plan converted to money - which roles, how many months, at what cost rate - plus direct costs like software licences, subcontractors, travel, and a share of overheads if the firm allocates them. The difference is the planned margin, and stating it in advance is the point: a project priced at NPR 60 lakh with NPR 52 lakh of planned cost is a 13% bet, and everyone should know that before signing.
The budget then becomes the measuring stick. Each month, actual cost accumulated against the project compares to the budget consumed - not to the total budget, but to where the budget said the project should be by now. A portal project that has burned 70% of its cost budget while delivering 40% of its scope is in trouble today, regardless of how much contract value remains to invoice. That comparison is only possible because a budget existed and actuals were coded to the project.
Nepal's project-based service sector is growing on every front: IT companies exporting development work to Australia, the US, and Europe; engineering consultancies supervising DoR and DUDBC contracts with government-prescribed deliverable schedules; architecture firms in Kathmandu juggling a dozen concurrent designs. Each context adds its own pressure - export clients expect professional invoicing and time evidence, government assignments carry fixed fee schedules where cost overruns are simply absorbed, and local private clients negotiate hard on price. In every case, the firm that knows its project economics negotiates from knowledge; the firm that does not is guessing at its own break-even.
Budgets also need revision discipline. When scope grows - and in Nepal's relationship-driven market, clients ask for "one small addition" constantly - the budget should be formally amended alongside a fee variation, or the addition explicitly accepted as an investment in the relationship. What must not happen is the silent version: scope grows, the budget stays, and the project's failure is discovered at closeout and blamed on the delivery team.
Set a revenue budget, a cost budget, and a stated margin before each engagement starts, then compare actuals to the budget phase by phase - and amend the budget formally when scope changes, so the project is always measured against a plan that reflects reality.
Allocating People and Costs - Where Project Profit Becomes Real
The hard part of project accounting in a service firm is that the dominant cost - salaries - arrives as one monthly payroll, not as project invoices. Allocation is what converts it: each person's time, recorded against projects through timesheets, multiplied by their cost rate, lands as project cost. A senior developer costing the company NPR 250,000 a month who spent 60% of the month on the banking portal just added NPR 150,000 to that project's cost - whether or not anyone invoiced anything. Direct expenses follow more easily: licences, subcontracted work, travel, and hosting are coded to their projects at entry.
Billing model shapes what the allocation reveals. Time-and-materials engagements convert hours into revenue as well as cost, so margin is visible per hour. Fixed-price engagements are where allocation matters most - the revenue is capped, so every additional allocated hour eats the margin directly, and only cost tracking shows how much of the fixed fee remains.
- Fixed-price contracts reward efficiency - deliver in fewer hours and the margin expands
- Clients commit faster to a known total than to an open-ended rate
- Revenue is predictable for cash flow planning and staffing decisions
- Every scope addition and estimate error comes out of your margin, not the client's budget
- Weak requirements at signing translate directly into unpaid work later
- Without hour tracking against the fee, the loss is invisible until the project ends
Overhead allocation deserves a deliberate policy rather than perfectionism. Rent, administration, and management time can be spread over projects by headcount-months or direct cost - the method matters less than consistency. Many firms run two views: a contribution view (revenue minus direct project costs) for engagement decisions, and a fully-loaded view for pricing policy. Both are legitimate; confusing them is not.
People are the product in a service firm, so timesheet-driven cost allocation is the heart of project accounting. Fixed-price work makes it existential - the fee is capped, and only allocated hours reveal how much of it your team has already consumed.
Milestone Billing and the Profitability Answer
Milestone billing ties invoicing to deliverable completion: 20% on signing, 30% on design approval, 30% on user acceptance, 20% on go-live. Done well, it protects both sides - the client pays for demonstrated progress, and the firm's receivables track its actual delivery. Done casually, it creates the classic service-firm cash trap: work races ahead of invoicing, the firm quietly finances the client for months, and a dispute at the final milestone puts the entire tail of the fee at risk. The project accounting view keeps this honest by showing, per project, work performed against amounts invoiced - so unbilled effort is visible as the receivable it economically is.
With budgets, allocation, and billing in place, the profitability question finally has an answer. Our five-project company ran the analysis and found what the blended P&L had hidden: the prestigious banking portal - the firm's largest revenue line - earned 8% after allocation, gutted by unbilled scope additions. The Australian retainer earned a steady 32%. The government subcontract broke even once its payment delays were financed. The internal product consumed 18% of all staff time with no revenue. And the small retailer app, staffed by two mid-level developers who simply got on with it, earned 45% - the firm's best engagement, previously invisible.
That analysis changes behaviour the way no exhortation can. Pricing rises where margins were thin, scope-change discipline hardens on fixed-price work, the internal product gets a real budget and a decision, and the next sales conversation chases more work shaped like the retailer app. This is what project accounting is for - not neater books, but different decisions.
Bill against milestones so cash tracks delivery, then read the project-wise P&L with fresh eyes: in our example the flagship client earned 8% while the smallest project earned 45%. Firms that see these numbers price, staff, and sell differently within a quarter.
Frequently Asked Questions
Use timesheets and cost rates. Each person records hours against projects; each person carries a cost rate - typically monthly cost to company (salary, SSF contribution, benefits) divided by available working hours. Hours multiplied by the rate become project cost. Two refinements keep it fair: use cost rates, not billing rates, so projects carry what people actually cost; and decide explicitly how non-project time - leave, training, internal meetings - is treated, usually by loading it into the cost rate rather than dumping it on whichever project someone happened to touch that week. The allocation will never be perfect to the minute, and does not need to be - consistent 90% accuracy beats a precise system nobody maintains.
Cost centers are permanent organizational units - departments, branches, teams - that accumulate cost year after year for control and budgeting. Projects are temporary economic events with a start, an end, a revenue side, and a final answer: did this engagement make money? A service firm generally needs both dimensions on the same transactions: the department view for managing capacity and overheads, and the project view for engagement profitability. The practical implication is that your accounting system should let one voucher carry both a cost center and a project code, so neither view requires re-entering anything.
Yes - especially because they have no invoice forcing the question. An internal product, a website rebuild, or a research effort consumes the same expensive hours as client work, and untracked internal time is where service firm capacity quietly disappears. Give each internal initiative a project code and a budget, allocate time to it honestly, and review it with the same monthly discipline. The point is not to kill internal investment - it is to make it a decision. In our worked example, discovering that an internal product consumed 18% of all staff time converted a vague ambition into a funded plan with a deadline, which is healthier for the product and the firm alike.
Project-Wise Truth From the Same Books You Already Keep
MISAC's custom fields put a project dimension on every module without a developer: project codes on invoices, payments, expenses, purchase orders, and timesheet entries, applied at entry rather than reconstructed at month-end. Task management with per-staff time tracking feeds the allocation engine, travel claims and expenses code themselves to engagements, and validation rules can make the project field mandatory - so the "for which project?" discipline is enforced by the system, not by reminders.
Custom financial statement grouping then turns those coded transactions into the reports this article describes: a project-wise P&L laid out exactly as your management wants to read it, a contribution view and a fully-loaded view from the same data, and budget versus actual per project without a single Excel export. Pivot reporting lets you slice margin by client, project type, or team - which is how the 45% engagement stops being invisible.
MISAC Intelligence Pvt. Ltd. has spent over a decade building financial systems for Nepal's service businesses, from IT exporters to engineering consultancies. If your firm is profitable but cannot say which projects made it so, we would be glad to show you your own numbers, project by project.
Ready to See MISAC in Action?
If you cannot name your most and least profitable project today, talk to us about project accounting built for Nepali service firms.