Most firms know their overall margin. Far fewer can tell you, on the eighteenth of the month, which of their live engagements is quietly losing money. The number exists, but it is spread across a timesheet tool, an expense app, a spreadsheet of rates and a general ledger that only sees the invoice. Professional services accounting software exists to put those four things in one place while the project is still running.
That is a different requirement from what general accounting packages are built for. A product business can manage with a good ledger and a decent chart of accounts. A firm that sells time cannot, because the profitable unit is the engagement, and the engagement crosses periods, people, entities and billing methods.
This is what implementing project-based accounting actually involves: what you have to decide before configuration, where profitability visibility breaks in practice, and what the finance team’s month looks like once the numbers arrive on their own.
Key Takeaways
- The profitable unit in a services firm is the project, so cost, time, expense and revenue all have to reconcile at project level, not just at company level.
- Project hierarchy is the decision that shapes everything else. Too coarse and margin is invisible; too granular and nobody codes their time honestly.
- Project profitability reports are only as fresh as the last timesheet. Fixing the time entry deadline usually does more for visibility than any dashboard.
- Multi-entity firms have to settle the intercompany rule for shared people before configuration, because it determines whether project margin reads gross or net at entity level.
- Name one system of record for project creation. CRM, PSA and finance all creating projects produces three IDs for one engagement.
- After go-live, project managers stop asking finance for their numbers. Somebody new has to own project setup templates and rate tables.
Screenshots throughout are Sage Intacct product material. The figures shown in them are Sage’s demonstration data, not Lucentive client results.
What professional services accounting software has to do differently
A services firm sells time and expertise, so its unit of profit is the engagement rather than a product line. Project accounting software has to capture cost, time and expense against a project, bill it under whatever method the contract specifies, and still produce a clean general ledger, without a spreadsheet sitting between those two jobs.
That applies across a wide range of firms: consulting, IT services, digital marketing, advertising, engineering, research, HR services and professional employer organizations. It also applies inside software companies, where “professional services” usually means the implementation and onboarding arm that bills time against a signed statement of work and is measured on realization rather than license revenue.
The common requirement underneath all of them is that three sets of numbers have to reconcile continuously: the hours people worked, the cost of those hours, and the revenue recognized against them. General accounting software reconciles the third one accurately and the first two by export. That gap is the whole reason project based accounting software exists.
Project accounting: cost, time, expense and billing
A project accounting system tracks costs and hours against a project structure, captures expenses at the point they are incurred, and supports the billing methods your contracts actually use: time and materials, fixed fee, milestone, retainer, or a mix on the same engagement. Billing and revenue then flow to the ledger without rekeying.
The hard part of implementation is not the billing rules. It is the project hierarchy. Every firm has to decide how deep the structure goes: client, engagement, phase, task, deliverable. Too shallow and you can see that a client is profitable but not which workstream is dragging. Too deep and your consultants face a timesheet with forty valid codes on a Friday afternoon, and they will pick whichever one is at the top of the list.
The test worth applying is whether anyone would decide differently because of the extra level. If splitting a phase into six tasks would not change how you staff, price or scope the next one, it is detail you pay for in data entry accuracy and get nothing back for. Start shallower than feels right.
The cost side of that structure deserves the same attention. Subcontractor bills, travel and per-client purchases only reach project margin if the project code is attached when the spend is approved, rather than corrected at month-end. Which payment rail the bill eventually leaves on matters much less, though it is the part vendor material tends to lead with.
Where project profitability actually breaks
Project profitability rarely breaks in the software. It breaks in five specific places, and every one of them is a process decision rather than a configuration setting. Naming them before you implement is what separates a project P&L people trust from one they quietly re-check in Excel.
- Timesheet latency. A project looks profitable right up until three weeks of hours land at once. If your time entry deadline is loose, your margin reporting is retrospective no matter what the dashboard promises.
- Uncoded non-billable time. Internal work, rework and pre-sales effort that never gets tagged to the engagement it belongs to makes delivery look cheaper than it was.
- Professional services expenses landing in overhead. Travel, subcontractor invoices and software bought for one client are project costs. If they are coded to a general expense account because that is faster, project margin is systematically overstated.
- Revenue and cost on different cadences. Fixed-fee work recognized on a milestone while cost accrues weekly produces margin that swings for reasons that have nothing to do with delivery.
- Change orders handled by email. Scope grows, the budget in the system does not, and the variance report blames the delivery team for something the contract already allowed.
None of these are solved by buying software. They are solved during implementation by deciding the time entry deadline, the non-billable coding scheme, the expense policy and the change order path, and then configuring the system to make the right behavior the easy one.
[DATA: A named Lucentive professional services client’s utilization or realization change after implementation, with permission to publish — Rich to confirm]
Managing multiple entities and accelerating consolidations
Growing firms accumulate entities: a second country, an acquired practice, a separate entity for a regulated service line. Sage Intacct maintains separate financials per entity while automating the consolidation, including currency conversion, inter-entity transactions and local tax reporting, so a close stops being an assembly job.
Here is the decision that catches multi-entity services firms, and it is almost never in the software evaluation. When a consultant employed by one entity works on a project owned by another, how does the cost move? You can charge it at cost, at a transfer rate, or leave it in the home entity and report project margin only at group level. Each choice produces a different entity P&L from identical delivery work, and each has a tax consequence.
Settle that rule before configuration, with whoever owns your tax position in the room. Retrofitting an intercompany policy after six months of posted time is genuinely painful, because it means restating both entity results and project margin. The wider case for centralizing this is covered in consolidating and automating finances across multiple entities.
Integrating CRM, PSA and the rest of your stack
Sage Intacct connects to the systems that surround project delivery through a prebuilt Salesforce connector, an open API and a library of prebuilt connectors for CRM, expense, payroll and PSA tools. The aim is that an opportunity becomes a project and a project becomes an invoice without anyone retyping a client name.
The failure mode is common. Sales creates an opportunity in the CRM with its own identifier, delivery creates a project in the PSA tool with a different one, finance creates a third in the ledger. Nothing is technically broken, and yet no report follows one engagement from sold to delivered to billed without a manual mapping table.
Fix it by naming one system of record for project creation and making the others receive rather than originate. In most firms the ledger is the right place, because that is where the project has to exist for costs to post. Decide the matching key too, and decide who is told when a sync fails, because a broken integration looks exactly like a slow month.
Reporting: P&L by project, manager, region and service line
Because Sage Intacct tags transactions with dimensions rather than encoding them into account codes, one set of postings supports profit and loss by project, service line, practice, manager, region, customer type or task. Secure user-based access then means a practice lead sees their own numbers without seeing everyone else’s.
That last point does more for adoption than any chart. A delivery lead who can open their own engagement margin without asking anyone starts managing to it. One who has to request a report from finance manages to the last one they were sent, three weeks ago.
The prerequisite is a dimension structure decided before migration rather than after. Project, service line, practice and region are all dimension candidates, and which ones are mandatory on which transaction types determines whether your reports tie back to the ledger. That design work is worth doing properly, and how dimensions reshape a chart of accounts is the place to start.
Sequencing the implementation and what changes after go-live
A workable order is: chart of accounts and dimensions, then project structure and rate tables, then time and expense capture, then billing methods, then revenue recognition, then dashboards, then the CRM or PSA integration. Reporting comes late because it inherits every earlier decision, and integration comes late because it is the one piece that depends on another team’s calendar.
Two adjacent notes. Firms that bill against physical progress rather than hours, such as engineering practices doing design-build work, usually need percentage of completion and retainage handling too, which is closer to construction job costing and WIP than to classic time and materials. And the planning effort itself deserves realistic estimation, which is covered in planning the costs, time and resources for an ERP implementation.
[DATA: Lucentive’s typical professional services implementation timeline from kickoff to first live project P&L — Rich to confirm]
After go-live the change is less about speed than about who holds the information. Project managers stop emailing finance for numbers. Finance stops assembling and starts reviewing exceptions: engagements trending past budget, unbilled balances aging, realization slipping on a service line. One new responsibility appears and is worth assigning on purpose: somebody owns project setup templates, rate tables and approval of new project codes. Left to whoever gets there first, rate tables drift within two quarters.
Summary
Professional services accounting software earns its place when it makes engagement-level profitability visible while the engagement is still running. That requires project structure, time and expense capture, contract-appropriate billing, multi-entity handling and dimensional reporting working as one system rather than four tools joined by exports.
The decisions that determine whether it works are made before configuration: how deep the project hierarchy goes, when timesheets are due, how non-billable time is coded, what the intercompany rule is for shared people, and which system creates a project. Software makes the right behavior easier. It does not choose the behavior for you.
One note on the proof that arrives with an evaluation pack. Review-site awards are real, and they are about the product, decided by the people using it rather than by anyone selling it. They are worth exactly that much and no more: they say nothing about whether the partner configuring your project structure has done it before.
The version of this page we retired offered an infographic, a case study and a benchmark report behind a form. Those are useful for building a business case and useless for answering the question most firms actually have, which is whether their own project structure will survive contact with a real system. Talk to Lucentive and bring your current project list and rate card. Our consultants have 25+ years each in project-based finance, and that conversation is more useful than any download.
Frequently asked questions
What is professional services accounting?
Professional services accounting is accounting organized around engagements rather than products. Costs, hours and expenses are captured against a project, revenue is recognized according to the contract type, and profitability is measured per engagement as well as per entity. The defining difference from general accounting is that the ledger has to reconcile with time and cost data continuously, not only at period end.
What is the difference between project accounting software and general accounting software?
General accounting software records what was billed and what was spent, organized by account. Project accounting software additionally tracks cost, time, expense, budget and revenue against a project structure, so you can see margin per engagement while it is live. In practice, firms without it reproduce the missing half in spreadsheets, which is why project margin is usually a month behind the ledger.
Can project accounting software work for a small firm?
Yes, and the question is usually about complexity rather than headcount. A ten-person firm with fixed-fee work across two entities and multiple currencies has a harder accounting problem than a forty-person firm doing straight time and materials in one entity. The signals that a small firm has outgrown basic tools are usually multiple entities, mixed billing methods, or project margin that only exists in a spreadsheet.
What professional services expenses need to be tracked at project level?
Anything incurred because a specific engagement exists: travel, subcontractor and contractor invoices, per-client software or data purchases, materials and pass-through costs. The common error is coding these to general overhead accounts because it is faster at entry. That single habit overstates project margin consistently, and it is worth fixing during implementation by making the project field required on expense and payables transactions.
How does project accounting handle multiple entities and currencies?
Each entity keeps its own books while consolidation, currency conversion, inter-entity transactions and local tax reporting are automated at group level. The decision that matters most is how shared people are charged between entities, because charging at cost, at a transfer rate, or not at all produces three different entity results from the same delivery work. Settle that rule with your tax adviser before configuration.