Project Management in Business Central: The Jobs Module

Most people who implement Business Central meet the Jobs module late, after finance, after sales, after purchasing, and they meet it because someone in the room finally asks the awkward question: are our projects actually making money? That question is harder to answer than it sounds, because a project is a moving target. Costs land over weeks or months, revenue is recognised on a different rhythm entirely, and for the whole time the project is open your accounts have to reflect a partly-finished piece of work without either overstating the profit or hiding the cost. The Jobs module, which Microsoft has renamed Projects in recent versions, is the part of Business Central built to hold that tension. This guide walks through how it actually works, from the project card down to the work-in-process posting, in the order a practitioner would build it.

The message up front: the Jobs module is not really about tracking tasks, it is about profitability visibility. Everything in it, the planning lines, the resources, the time sheets, the job journals, exists to answer one question at any moment: what has this project cost so far, what will it cost to finish, and what will it be worth. If your setup does not make that answer easy to read, you have configured the mechanics but missed the point.

1. Jobs and Projects: the same module, a new name, and what it is for

If you have worked with Business Central or its predecessor NAV for any length of time, you know this functionality as Jobs. If you are coming to a recent version fresh, you will see it labelled Projects. They are the same module. Microsoft renamed Jobs to Projects across the application, so the page that used to be the Job Card is now the Project Card, the Job Journal is the Project Journal, and the various job ledger concepts carry the Project name in the newer interface. I will use both names through this guide, because in the field you will meet consultants, partners and older documentation that still say Jobs, and you will meet newer users who have only ever seen Projects. Underneath the label the objects, the ledger entries and the posting logic are the same, so nothing you learned about Jobs is wasted.

The purpose of the module is to let you manage a discrete piece of deliverable work, a project, as a first-class financial and operational object. A project in this sense is any bounded effort you want to plan, cost, resource and bill separately from the rest of the business: an installation, a consulting engagement, a construction package, a fit-out, a bespoke manufacturing build, a facilities upgrade. The module gives that effort its own structure of tasks, its own budget, its own record of what was consumed against it, and its own path to an invoice. Crucially, it does all of this while remaining wired into the general ledger, so a project is never an island of numbers that has to be reconciled back to finance by hand.

It helps to be clear about what Jobs is not. It is not a full project-planning tool in the sense of a dedicated scheduling application with Gantt dependencies, critical-path calculation and resource-levelling algorithms. It tracks tasks and dates, but it is not trying to replace a specialist planning package for complex programmes. What it does exceptionally well is the money: it connects the effort and materials that go into a project to the cost and revenue that come out of it, and it keeps the accounting straight the whole way through. If you understand the module as the financial backbone of project delivery rather than as a scheduling engine, you will set it up correctly. For where it sits among everything else the platform does, the complete features guide maps the module against the rest of Business Central.

2. Project (job) cards, tasks and planning lines

Every project starts with a project card, formerly the job card. This is the header record that carries the identity of the project: its number, description, the bill-to customer, the person responsible, the currency, the status, and the accounting choices that govern how the project posts. Two settings on the card matter more than any other because they steer the entire financial behaviour of the project: the WIP method and the WIP posting method. I will come back to those in the work-in-process section, but it is worth knowing from the outset that decisions made on the card determine how the project touches your financial statements, so the card is not just descriptive, it is a control panel.

Below the card sit the project tasks, formerly job tasks. Tasks are the structural breakdown of the project, and they are more than labels. They are the line items on which everything else hangs and the level at which most reporting rolls up. Tasks can be of different types: a posting task is one you actually charge costs and revenue against; heading, total and begin-total tasks are structural, giving you subtotals and grouping so a large project reads like a tidy statement rather than a flat list. A well-structured task list is the difference between a project you can read at a glance and one you have to decode. On a construction fit-out you might have heading tasks for each trade, posting tasks beneath them for labour, materials and subcontract, and total lines that sum each trade and the project overall.

Under each posting task live the planning lines, formerly job planning lines, and this is where the real detail lives. A planning line is a single planned line of activity: this much of this resource, or this quantity of this item, or this general-ledger expense, expected on this task, with a cost and a price. Planning lines are the estimate and the plan expressed in the same records that will later be measured against reality. Business Central distinguishes planning lines by their line type, and understanding that distinction is central to using the module well, because the line type decides whether a line is part of the budget, part of what you will bill, or both.

The thing I stress to every team learning this module: the task and planning-line structure you design at the start becomes the shape of every report you read for the life of the project. Get the breakdown right, matching how you actually think about the work and how you want to see profitability sliced, and the module rewards you with clean, readable numbers. Design it carelessly, with everything charged to a single flat task, and you will have a project that posts correctly but tells you nothing useful about where the money went.

3. Budget versus billable: the schedule and the contract

The single most important concept in the Jobs module, and the one that trips up almost everyone at first, is the split between the schedule side and the contract side of a project. Business Central holds two parallel views of every planning line, and it uses the line type to decide which view a line belongs to. Get this clear and the rest of the module falls into place.

A planning line marked as Budget (called Schedule in some versions) represents what you expect the project to cost you and the effort you expect to consume. It is the internal estimate. It says: to deliver this, I plan to use forty hours of a senior engineer, this list of materials, and this subcontract expense. Budget lines drive your cost expectation and your resource loading, but on their own they do not create anything you can invoice.

A planning line marked as Billable (called Contract in some versions) represents what you intend to charge the customer. It is the external, revenue-facing view. It says: for this work I will invoice the customer this amount. Billable lines are what feed the project sales invoice. They are the contract with the customer expressed as line items.

A line can also be marked as Both, meaning it is simultaneously part of the budget and part of what you will bill. This is the common case on a time-and-materials job, where every hour you plan to spend is also an hour you plan to charge. On a fixed-price job the two sides deliberately diverge: your budget lines describe the cost of delivery, while a separate set of billable lines describes the agreed contract value, and the gap between them is your planned margin. That divergence is not a mistake, it is the whole point. The module lets your cost plan and your revenue plan be different numbers, which is exactly what real project commercials require.

The insight that unlocks the module: budget and billable are not two lists of the same thing, they are the two halves of your project margin. Budget is what it costs you, billable is what you charge, and the module exists to track both against reality at the same time. Once you stop thinking of planning lines as a to-do list and start thinking of them as one side of a margin calculation, every setting in Jobs starts to make sense.

4. Resources and resource management (resource cards, capacity, costs and prices)

Projects do not deliver themselves. They are delivered by resources, and resource management in Business Central is a genuinely capable subsystem that deserves proper attention rather than the afterthought treatment it often gets. A resource is anything that performs billable or costable work on a project: most often a person, but also a machine, a piece of equipment, a vehicle, or any capacity you want to plan, cost and charge. Resources are shared across the whole application, so the same resource record can be used on projects, on service orders and on assembly, which means getting the resource setup right pays off well beyond the Jobs module alone.

Each resource has a resource card, and the card carries the economics of that resource: its unit cost, which is what an hour of this resource costs your business, and its unit price, which is the default rate you charge for an hour of it. It also carries the base unit of measure, typically hour, and the general product posting group and other posting attributes that decide how the resource lands in the ledger when it is consumed. The direct unit cost and the unit price on the card are the defaults that flow onto planning lines and journals, so setting them accurately is the foundation of trustworthy project costing. A resource whose cost rate is wrong will quietly poison the margin on every project it touches.

Resources can be grouped into resource groups, which lets you plan and report at the level of a team or a skill category rather than an individual. You can plan a project against a resource group when you know you will need a senior engineer but have not yet decided which one, and assign the specific person later. This matters for both planning flexibility and for capacity, because capacity is the other half of resource management.

Business Central lets you define resource capacity: how many hours a resource is available in a given period, set through the resource capacity functionality where you enter the working hours for each resource across a calendar. Once capacity is defined, you can compare the demand your projects place on a resource against the capacity that resource actually has, and see where you are over-committing someone or leaving them idle. This is not a heavyweight resource-levelling engine, and I would not pretend it competes with a specialist professional-services-automation tool for complex multi-project scheduling. But for a business that wants to know whether its planned project work fits inside the hours its people have, it is honest, usable capacity visibility built into the same system that holds the costs.

Pricing deserves its own note, because resource pricing in Business Central is more flexible than the single rate on the card suggests. You can define resource prices and resource costs that vary by resource, by resource group, by work type, and by the specific project or project task. Work types are a particularly useful lever: the same engineer might be charged at a standard rate for normal work, a higher rate for overtime, and a different rate again for travel, all captured through work type codes that carry their own pricing. This means a single resource can bill at several rates depending on what kind of work they did, which reflects how professional-services and field businesses actually invoice. Setting up a sensible work-type and pricing structure once saves an enormous amount of manual rate-adjustment later.

The honest limitation: resource management in Business Central is good at cost, price and capacity, but it is not a full workforce-scheduling or skills-matching engine. It will tell you whether a resource is over-committed; it will not automatically optimise who does what across a portfolio of projects, and it has no real notion of individual skills, certifications or preferences beyond what you model with groups and work types. If your business lives or dies on sophisticated multi-project resource optimisation, plan to complement the module rather than expecting it to do that job alone.

5. Time sheets and capturing effort

The most valuable and most fragile input to any project is the record of time actually spent, because on most project businesses labour is the largest cost and the primary thing you bill. Business Central captures this through time sheets, a structured weekly record where a resource logs the hours they worked, against which project and task, and of what type. Time sheets are the disciplined bridge between what people did and what the project ledger records they did.

A time sheet in Business Central runs on a weekly cycle and moves through a small approval lifecycle. The resource, or a designated time sheet owner, enters lines for the week: so many hours on this project task, so many on another, some against absence or non-project categories. Each line has a status, and the sheet moves from open, to submitted, to approved, with an approver signing off before the time becomes accounting-relevant. That approval step is not bureaucracy for its own sake; it is the control that stops unreviewed hours flowing straight into a customer invoice or a cost posting. On any project business, someone accountable should be looking at the hours before they become money.

Once time sheet lines are approved, they can be transferred into the project, becoming project planning lines or feeding the project journal so that the hours post as usage against the relevant task. This is the mechanism that turns a person saying "I spent six hours on the Al Reem installation on Tuesday" into a costed, and potentially billable, entry on that project. Time sheets can also feed other areas, such as service and jobs together, but for the Projects module their central role is to capture the labour that is usually the dominant line in project cost.

My practical warning on time sheets is a people warning, not a software one. The module works exactly as designed, but it only works if the hours actually get entered, entered promptly, and entered accurately. A project business that lets time sheets slip by two or three weeks is a business flying blind on its single largest cost, and no amount of clever configuration fixes a culture that does not fill in the sheet. Make time entry a weekly habit with a real deadline, wire the approval to someone who cares about margin, and the module gives you timely, trustworthy labour data. Let it slide and every downstream number, cost, WIP and profitability, is late and wrong.

6. Job journals: posting costs and usage

Planning lines are the plan. The job journal, now the project journal, is where reality gets recorded. When a resource works, when an item is consumed, or when a general-ledger cost is incurred against a project, it is posted through the project journal, and that posting creates project ledger entries that record the actual usage of the project. This is the moment the estimate meets the world, and it is the mechanism that lets the module compare what you planned against what actually happened.

There are a few flavours of journal in play. The project journal posts usage, the cost side: hours consumed, materials drawn, expenses incurred. The project G/L journal handles general-ledger-based project costs. And when you invoice, the sales side posts through the project sales invoice rather than the journal. What unites them is that every posting is tagged to a project and a task, so the project ledger accumulates a complete, itemised history of everything that has been consumed by, or charged to, the project. That accumulation is the raw material for every profitability figure the module produces.

A subtle but important point is the relationship between planning lines and actual postings. When you post usage against a project, Business Central can relate that usage back to the planning lines, so you can see, task by task, how much of what you planned has actually been used and how much remains. This is what turns the module from a passive recorder into an active management tool: it does not just tell you what you spent, it tells you what you spent against what you said you would spend, which is the early-warning system for a project drifting over budget. A task that is eighty percent through its budgeted hours with half the work still to do is a problem you want to see in week three, not at final invoice.

Items consumed on a project flow through the same inventory logic as the rest of the system, so posting an item as project usage decrements stock and posts the item cost to the project, keeping inventory and project accounting consistent. This is one of the quiet strengths of doing projects inside a full ERP rather than a standalone project tool: the materials you consume on a project are the same materials your warehouse tracks, valued the same way, with no reconciliation between two systems. The project is not a separate ledger to be trued up later; it is part of the same connected whole.

7. Work in process (WIP) and cost recognition

This is the section that separates people who use the Jobs module from people who understand it, and it is where the module earns its place in a serious finance function. The problem WIP solves is fundamental to project accounting: costs and revenue on a project rarely land in the same period. You might incur three months of cost before you raise a single invoice, or you might invoice a large advance before you have done most of the work. If you simply let costs hit the profit and loss as they occur and revenue hit as you invoice, your monthly accounts would swing wildly, showing heavy losses in cost-heavy months and false profits in billing-heavy ones, none of which reflects the true economics of the project.

Work in process is the mechanism that corrects this. Instead of letting project costs and sales flow straight to the income statement, WIP moves them onto the balance sheet while the project is running, holding them as an asset or liability, and only recognises profit in the income statement in a way that reflects the true progress and economics of the project. In accounting terms it is the matching principle applied to projects: match the revenue you recognise to the cost of the work actually done, regardless of when the invoice happened to be raised.

Business Central offers several WIP methods on the project card, and the choice determines how and when profit is recognised. The methods reflect the standard approaches to long-term contract accounting: recognising based on the cost incurred so far relative to total budgeted cost, recognising based on the value of work performed relative to the contract, recognising cost as incurred while deferring revenue, or holding everything until the project completes and recognising only at the end. Each method suits a different commercial reality, from a percentage-of-completion basis for long construction contracts to a completed-contract basis for short jobs where you would rather recognise nothing until you are done. The right choice is an accounting-policy decision that should be made with your finance function and, where relevant, your auditors, not a setting to be picked at random on the card.

The caution I always give: WIP is powerful and it is also the easiest place in the whole module to get into trouble. The WIP method must match your accounting policy, the calculation has to be run and posted on a disciplined schedule, and the resulting balance-sheet entries need to be reviewed by someone who understands what they represent. A WIP setup left unrun for months, or misconfigured against your policy, produces financial statements that look precise and are quietly wrong. If you take one thing seriously in this module, take WIP seriously, and involve your accountant before you go live.

Mechanically, calculating WIP in Business Central is a run-and-post cycle: you calculate the WIP for a project, which works out the amounts that should sit on the balance sheet given the method and the actual costs and sales to date, and then you post the WIP to the general ledger, creating the entries that hold cost and revenue in the right place until the project completes and everything is recognised. This is typically done as a period-end routine across all open projects, and it is exactly the kind of task that benefits from being scheduled and owned rather than done ad hoc. When the project finally completes, the WIP is reversed and the full profit lands in the period the work genuinely finished, which is the whole point.

8. Invoicing projects (fixed price, time and materials, milestones)

Everything so far has been about knowing what a project costs and what it should earn. Invoicing is where the earning becomes an actual sales document and, eventually, cash. In Business Central you invoice a project by creating a project sales invoice that pulls from the billable planning lines, so the same lines that expressed what you intended to charge become the lines on the customer's invoice. The module supports the three billing models real project businesses use, and the flexibility of the planning line is what makes all three possible from one mechanism.

Time and materials is the most direct model. You bill for what you actually did: the hours resources logged and the materials consumed, at the agreed rates. Here the billable lines track the usage closely, and you typically invoice periodically for the effort and materials posted in the period. Because usage and billing are tightly linked in this model, the accuracy of your time sheets and job journals translates directly into the accuracy of your invoices. Sloppy time capture means under-billing, which is one of the most common and least visible ways a project business leaks margin.

Fixed price is where the budget-versus-billable split earns its keep. The customer agreed a total price regardless of what the work actually costs you, so your billable lines reflect that agreed contract value while your budget lines track your real cost. You invoice against the fixed price, often in stages, and your margin is the gap between the fixed revenue and your accumulating cost. On fixed-price work, WIP and cost recognition matter most, because the timing of your invoices and the timing of your costs almost never line up, and only proper WIP handling keeps your monthly profit honest while the project runs.

Milestone billing is the practical middle ground for larger projects, and it is really a way of structuring a fixed-price contract into billable stages. You agree that on completion of defined milestones, design approved, equipment delivered, system commissioned, a set amount becomes billable. You represent these as billable planning lines tied to the milestones, and you invoice each as it is reached. This aligns cash flow with delivery progress and gives the customer a clear payment schedule tied to tangible achievement, which is why it dominates construction, systems integration and large installation work.

Whichever model you use, the invoice posts back against the project, so the sale is recorded as project revenue on the same tasks the costs sit on, and the profitability picture stays complete. The billing model is a commercial decision made with the customer; the module's job is to make sure that whatever you agreed, the resulting invoices and the resulting project accounting stay consistent with each other and with the general ledger. Note that this project billing is distinct from recurring or contract-based service billing, which lives in a different part of the application; if your work is ongoing maintenance rather than discrete deliverables, the contrast with service management is worth understanding before you decide which module fits.

9. Project reporting and profitability analysis

All the structure and posting discipline exists to produce one thing: a clear, current view of whether each project is making money. Business Central gives you this in several layers, and knowing which layer answers which question keeps you from drowning in detail or, worse, trusting a headline number you do not understand.

At the top sits the project card itself, which surfaces summary statistics: the budgeted cost and price, the usage and sales to date, and the resulting cost, price and profit figures at both the schedule and the contract level. This is the at-a-glance health check for a single project, and for many managers it is the view they live in day to day. Beneath it, the project ledger entries provide the itemised history, every hour and every item and every expense, which is where you go when the summary looks wrong and you need to find out why.

The genuinely valuable reporting is the comparison views, because a single project's cost means little without context. The module lets you compare, task by task, the budget against the actual usage and the contract against the actual sales, which is the difference between planned and real on both the cost and the revenue side. That comparison is your project profitability analysis: it tells you not just what a project made, but where against the plan it made or lost it, which task overran, which was underbilled, which resource cost more than estimated. That level of insight is what lets you both manage the current project and estimate the next one better, because last project's variance is next project's more realistic budget.

A point I make to every project business: the most useful number the module produces is not final project profit, it is profit-to-date and estimate-to-complete while the project is still open and you can still do something about it. A project that reports a healthy profit after it closes is a nice historical fact. A project that shows you in week four that it is trending fifteen percent over budget is actionable intelligence, and it is worth far more, because you can still change the outcome. Configure your reporting to surface in-flight variance prominently, not just post-mortem profitability, and the module shifts from a record-keeper to a management tool. This is the profitability visibility that justifies the whole module.

10. Integration with finance and the wider system

The reason to run projects inside Business Central, rather than in a standalone project tool bolted onto your accounts, is integration, and it is worth being concrete about what that buys you. Every cost you post to a project simultaneously hits the general ledger through the posting groups on the resources, items and accounts involved, so there is never a separate project ledger to reconcile back to finance. The project and the accounts are the same set of books viewed two ways. When you post an hour of resource time to a project, the cost lands in the P&L, or on the balance sheet via WIP, in the same transaction that records it against the project task. Nothing is double-entered and nothing drifts out of agreement.

This connection runs in every direction. Items consumed on projects flow from and value against the same inventory the warehouse manages. Resource costs feed from the same resource records used across service and assembly. Project invoices become customer ledger entries and feed receivables, aging and collections exactly like any other sale. Project purchases, subcontract and bought-in materials, can be posted straight to the project from purchase documents, tying the payables side in too. And the WIP postings integrate with the general ledger so your balance sheet reflects the true position of work in progress across every open project. The project module is not a satellite; it is a lens onto the same connected financial core that runs the whole business. For the accounting backbone all of this posts into, the chart of accounts, posting groups, dimensions and period-end mechanics, see the financial management guide, which is essential background for anyone configuring the WIP and posting side of Projects.

Dimensions deserve a specific mention because they are the thread that ties project reporting to the rest of your management reporting. Because project postings carry dimensions like any other transaction, you can slice project profitability by department, by region, by customer group or by any dimension you have defined, and you can consolidate project performance into the same analysis views you use for the rest of the business. A project is not reported in a separate dialect; it speaks the same dimensional language as every other transaction, which means project performance folds cleanly into company-wide reporting rather than sitting off to the side in its own spreadsheet.

Final thoughts

The Jobs module, now Projects, is one of those parts of Business Central that looks modest until you understand what it is really doing. On the surface it tracks tasks and hours. Underneath, it is running a full parallel accounting of every project you deliver, holding the tension between costs that land early and revenue that lands late, keeping your financial statements honest through WIP, and giving you a live read on whether each engagement is actually profitable. That profitability visibility, project by project, task by task, while the work is still in flight, is the real prize, and everything else in the module, the planning lines, the resources, the time sheets, the journals, exists to feed it.

If you are implementing it, my advice is to start from the money and work backwards. Decide how you want to read profitability, design your task and planning-line structure to produce exactly those views, set your resource costs and prices honestly, get your WIP method agreed with finance before go-live, and build a genuine habit of timely time entry. Do those things and the module becomes the quiet backbone of a project business that always knows where it stands. Skip them, treat it as a task list with an invoice on the end, and you will have a system that posts correctly and tells you nothing you can act on. The mechanics are not hard. The discipline of pointing them at the right question, are we making money on this project, is what turns the Jobs module from a feature into an advantage.

Related reading: Financial management in Business Central, Service management in Business Central, Business Central features: the complete guide.