ERP system development
in Washington, D.C.

Many businesses sell work by the job. An engineering firm quotes a design package, a contractor prices a fit-out, a consultancy signs a fixed-fee engagement. The general ledger can tell such a company whether the quarter was profitable. It cannot tell which jobs made the money and which quietly lost it. That answer comes from project costing, and it is one of the strongest reasons to build an ERP around the way the business actually works.

The idea is simple. Every cost that belongs to a job carries the job code. Labour hours, subcontractor invoices, materials, travel and equipment hire all land on the project as well as in the ledger. Revenue lands there too. The difference is the margin of that job, visible while it is still running.

Labour is usually the largest and the messiest part. Hours arrive through timesheets, and timesheets are where most project costing schemes fail. People fill them in late, guess, or book everything to one familiar code. A custom system can make the right entry the easy one. Show each person only the jobs and tasks they are assigned to. Offer a daily entry screen rather than a weekly grid that gets completed from memory on Friday afternoon. Let a manager approve hours with one action per person per week.

The cost of an hour is its own design question. A simple rate per role is easy to explain and easy to audit. A fully loaded rate that includes payroll taxes, benefits and a share of overhead gives a more honest margin, but the numbers change whenever salaries change. Decide this before development starts. Changing the costing basis later means restating every open job.

Billing rules sit on top. Time and materials jobs bill the hours at a sell rate. Fixed-fee jobs bill against milestones, and the hours only measure how much of the fee has been consumed. Retainers bill a flat amount and track usage against it. A well-built module keeps cost and billing apart, so one timesheet line can feed both without anyone copying numbers between screens.

Revenue recognition is the part accountants will ask about first. On a long fixed-fee job, revenue is often recognised by percentage of completion, measured by cost incurred against the estimate. That makes the estimate itself a controlled document. Keep versions. Record who revised it and why. A margin report is only as trustworthy as the budget it compares against.

Then there is the view managers actually open. A project manager wants budget, actual, committed cost and forecast to complete, on one screen, updated daily. Committed cost matters more than people expect. A purchase order for steel is not yet an invoice, but the money is already spoken for.

Finally, plan for the edge cases early. Hours booked to a closed job. A rate change halfway through a contract. A subcontractor invoice split across two projects. Each needs a rule, and the rule belongs in the specification, not in a support ticket raised after launch.

Laptops, vehicles, machines, fitted-out premises, licensed software. Every business owns things that last longer than a year, and each of them has to be depreciated. In many companies this still lives in a spreadsheet kept by one person in finance. It works until that person is on leave during the close, or until an auditor asks where a particular forklift is.

A fixed asset module inside the ERP replaces the spreadsheet with a register. Each asset is a record: description, category, location, custodian, serial number, acquisition date, cost, useful life and depreciation method. The system calculates the charge every period and posts it to the ledger. Nobody retypes a figure.

The register should start where the asset starts. When a purchase invoice is coded to a capital account, the ERP can create a draft asset automatically and ask finance to complete the missing fields. This closes the most common gap. Assets that were bought, paid for and never registered simply disappear from the books, and their depreciation is never charged.

Categories carry the defaults. A category for computer equipment might set a short useful life and straight-line depreciation. A category for buildings sets a long life. Vehicles might use a declining balance. When someone adds a new asset, the category fills in the method and the accounts, and the user only changes what is genuinely different.

Some companies need more than one set of books. The depreciation used for financial statements often differs from the depreciation allowed for tax. A custom register can hold several depreciation books per asset and calculate each on its own rules. The difference between them then feeds deferred tax without a separate workbook.

Life events matter as much as the purchase. An asset can be improved, which adds cost and sometimes extends its life. It can be moved to another department or cost centre. It can be impaired, sold, scrapped or stolen. Each event needs its own transaction type with its own posting logic. A disposal, for example, has to remove cost and accumulated depreciation and book the gain or loss against the sale proceeds. Done by hand, this is where errors hide.

Physical verification is the other half. Printing a tag with a barcode or QR code for each asset lets a staff member walk the office with a phone and confirm what is actually there. Missing items become a list for follow-up. Items found but not on the register point to purchases that skipped the process.

Reports close the loop. Finance needs an asset roll-forward for each period: opening cost, additions, disposals, depreciation, closing value. Operations wants to know what is due for replacement. Both come from the same register, which is the point of building it inside the ERP.