Projects in Business Central

Business Central's project module (called Jobs in older versions; Projects in newer ones) is built for services-led businesses that need to track time and cost against engagements and bill customers from them. It is genuinely capable for SMB consulting, agency, light professional services, installation, and field-work organisations — and stops short of being a full PSA (professional services automation) suite.

Projects and tasks

A project belongs to a customer and contains a hierarchy of project tasks. Each task has a budget and a billable plan. Tasks roll up into the project for profitability and WIP reporting.

Planning lines

Within a task, planning lines describe what is budgeted, billable, or both: hours of a resource at a sell rate, items consumed at cost, GL expenses. Planning is in three flavours — Budget (cost only), Billable (revenue only), or Both (combined). This separation makes it easy to model fixed-price work, time-and-materials, and capped engagements.

Resources and time

Resources (people or equipment) have unit costs and price lists. Time sheets let users enter hours by week against projects and tasks, which then post to job journals. Resource availability and basic capacity planning are included.

Posting and WIP

As resources consume time and items are issued to a project, job ledger entries record cost and the WIP module can defer those costs to the balance sheet via WIP journals, recognised as revenue and COGS on completion or percentage-of-completion.

Billing

Job Sales Invoices are created from billable lines, in advance or in arrears, with milestone schedules, retainers, and progress billing all supported.

WIP methods — the decision that bites later

The WIP setup is where project accounting projects go wrong, because the method chosen at implementation determines how revenue and cost hit the P&L for every project afterwards. BC ships several WIP methods — completed contract (nothing to P&L until the project closes), cost value, sales value, percentage of completion, and cost of sales — and the right one is an accounting-policy decision, not a system preference. Two practical warnings. First, the WIP calculation is only as good as the budget (percentage-of-completion divides actuals by budget, so an unmaintained budget produces confidently wrong revenue recognition). Second, WIP calculation and WIP posting are separate, deliberate steps — run monthly, reviewed by someone who understands the numbers, not automated into the dark. The mechanics get their own guide in WIP and recognition for jobs in BC, and the terminology in the WIP glossary entry.

Purchasing against projects

Cost doesn't only arrive through time sheets. Purchase order and purchase invoice lines carry project and task fields, so subcontractor invoices, materials, and expenses post straight onto the project as job ledger entries. This is also the discipline point: costs booked to a plain G/L account without the project reference simply vanish from project profitability, and no report finds them later. Make the project field effectively mandatory for project-driven purchase categories, and review "project-less" cost postings weekly during the first months.

Making it work in practice

• Time discipline is the whole game. Project profitability in BC is a report over job ledger entries; if consultants book hours weekly-ish and generously round, every downstream number is fiction. Weekly time sheet approval with a named approver is a process decision that matters more than any configuration.
• Model engagement types deliberately. Fixed-price work: budget lines as Budget, invoicing via Billable milestone lines. T&M: Both, so every posted hour creates a billable line. Mixing the patterns on one task produces double-billing or unbilled work.
• Keep the task structure shallow. Two or three levels. A task hierarchy mirroring a 200-line project plan makes time entry a treasure hunt and guarantees miscoded hours.
• Invoice from the system. Creating invoices in Word "because the layout is nicer" breaks the link between billed and posted amounts. Fix the document layout instead.

Limits — and when Project Operations earns its cost

Resource-level utilisation reporting, formal resource scheduling boards, and complex pricing/billing rules (multi-currency milestone with retention, for example) are basic. Companies that need full PSA — opportunity-to-cash for services with resourcing, scheduling, and complex billing — typically move to Project Operations, which is a separate Dynamics 365 app that integrates back to BC or Finance.

The honest dividing line: if projects are what you sell and the pain is in winning, staffing, and scheduling them — sales pipeline for engagements, bench management, skills-based resourcing — BC's module was never meant to solve that, and Project Operations is the answer. If projects are how you account for delivery and the pain is cost capture, WIP, and billing, BC's module is enough and considerably cheaper. Moving up for prettier Gantt charts alone is an expensive way to buy a picture; the comparison is walked through in BC jobs vs Project Operations.