Contracting 101: Your Project Accounting System Is Only as Good as Your Setup

You've received the contract award, reviewed the agreement, and you're ready to get started. Accounting establishes a project number, employees receive their charge codes, and everyone gets to work. Sounds simple enough, right?

Now imagine you're six months into performance and discover that the customer requires costs to be reported by location, but your accounting system wasn't configured to capture them that way. Suddenly, someone is spending hours manipulating spreadsheets, trying to reconstruct information that could have been captured from day one.

The frustrating part is that you may have a very expensive project accounting system capable of doing exactly what you need. You just didn't plan for it during setup.

Successful project setup isn't simply about creating charge codes. It's about understanding what information you'll need throughout the life of the contract and making sure your systems can capture it.

One Size Does Not Fit All

I've worked with companies that use a standard project structure for every contract and others that customize the structure based on the requirements of each award. There's nothing inherently wrong with either approach, and both have advantages.

Standardization can improve consistency, simplify reporting, and make project administration easier. But problems arise when a company becomes so committed to its standard structure that it stops considering whether that structure makes sense for the contract.

I once encountered a company whose standard project structure had seven levels. Every contract had to fit that structure, regardless of complexity. Even a relatively simple contract ended up with a charge code resembling:

12345.00.000.0000.00.00.LBR

Now imagine trying to explain all those levels to an employee who simply needs to charge time to one project.

On the other hand, creating a completely unique structure for every contract can introduce its own problems, particularly when companies need consistent reporting across projects. The goal isn't standardization or customization for its own sake. It's finding a structure that supports the contract without creating unnecessary complexity.

Think About the Information You'll Need Before You Need It

Before establishing a project, I like to consider the entire contract lifecycle, not just what Accounting needs to process the first invoice. The decisions made during setup can affect budgeting, cost accumulation, billing, revenue recognition, reporting, and ultimately contract closeout.

Some of the considerations I recommend reviewing include:

Consideration	What should you evaluate?
Contract and option years	Will costs, revenue, budgets, or reporting need to be separated by performance period?
CLINs and SLINs	What level of detail is needed for billing, funding, and financial reporting?
ACRNs and funding	Can obligations and expenditures be tracked against the appropriate funding sources and limitations?
Cost categories	Do labor, travel, materials, subcontracts, and other direct costs require separate tracking?
Location or PWS activity	Does the contract require reporting by site, location, task, or performance work statement element?
Labor categories	How will contractual labor categories, qualifications, and billing rates be managed?
Revenue and billing	At what level must revenue be calculated, invoices prepared, and billing reconciled?
Budgets and forecasts	Can Program Control compare budgets, actual costs, commitments, and estimates at completion at the necessary level?
Contract reporting	What information is needed for CDRLs, recurring reports, and annual reporting requirements?
Audit and closeout	Will the structure support applicable incurred cost reporting, reconciliations, and contract closeout?
Future changes	Can the setup accommodate modifications, additional funding, new work, and exercised options?

Not every item needs its own charge code or project level. Depending on the accounting system, information may be captured through project attributes, organizations, tasks, funding records, labor categories, or other reporting dimensions. The important thing is determining how the information needs to be captured before deciding how the project should be structured.

And don't forget to consider who will actually use the information. Accounting, Program Control, Contracts Administration, and Program Management may need different views of the same project. A structure that works beautifully for invoicing may not provide the detail needed to forecast costs or prepare a required customer report.

Read the Reporting Requirements, Not Just the Funding Documents

Here's a real example of why that matters.

I encountered a contract where the award documents didn't indicate that funding was separated by performance location. Based on the financial structure alone, there was no obvious reason to establish separate tracking by site. However, elsewhere in the agreement was a requirement to report costs by location.

We hadn't planned for that reporting requirement during project setup, and the accounting system wasn't configured to readily produce the information. What should have been a relatively straightforward report became an exercise in reconstructing and allocating costs after the fact.

This is why I encourage companies to look beyond Section B, the funding documents, and the billing instructions when establishing a project. A reporting requirement buried in the PWS, an attachment, or a CDRL can be just as important to your project structure as a CLIN or ACRN.

The question isn't just how the contract is funded or billed. It's what information the company will be expected to produce throughout performance.

Know What Your Accounting Software Can Actually Do

This is one of my biggest frustrations when reviewing established processes. Companies invest substantial amounts of money in sophisticated project accounting systems, then create complicated manual workarounds because they don't fully understand the software's capabilities.

I've seen employees moved to entirely new charge codes simply because their contractual labor billing rates changed. In Deltek Costpoint, for example, billing rate tables can be configured with effective beginning and ending dates. Depending on the billing setup, a rate change may be handled through the existing rate configuration rather than creating new project structures and moving employees between charge codes.

Instead, companies sometimes complicate their project structures, disrupt timekeeping assignments, and create additional reconciliation work to accomplish something their system may already be capable of handling.

And a little side note for my Costpoint users: If you've set up your billing rates and can't figure out why Costpoint isn't calculating them correctly, reach out. I may know exactly what's happening. 😉

The broader lesson applies regardless of which accounting platform you use. Before creating a new charge code, building another spreadsheet, or developing a manual process, make sure you understand what the software can do, how it's configured, and where its actual limitations exist.

Sometimes the answer isn't a workaround. It's learning how to use the system you already have.

Plan the Structure Before Project Kickoff

One of the best ways to avoid these problems is to involve the right people before the project structure is finalized, ideally before the project kickoff.

Contracts Administration should identify the contractual obligations, funding restrictions, billing provisions, and reporting requirements that may affect setup. Program Management should explain how the work will actually be performed, including tasks, locations, staffing, and subcontractor activities. Program Control and Accounting need to evaluate whether the proposed structure supports budgeting, forecasting, cost accumulation, revenue recognition, billing, and reporting.

Depending on the contract, other stakeholders such as HR, Security, Purchasing, or Subcontracts may also need to participate. In a small company, several of these responsibilities may belong to the same person, and that's perfectly fine. The important thing is making sure the necessary perspectives are represented.

And here's my favorite advice for these meetings: Don't invite people to tell you how great your proposed project structure is. Invite them to tell you why it won't work. 😂

Ask the difficult questions. Can Accounting generate invoices at the required level? Can Program Control produce the financial information it needs? Can the Program Manager get meaningful cost and performance reports? What happens when additional funding arrives, a new CLIN is added, or an option year is exercised?

A productive setup discussion isn't necessarily one where everyone agrees immediately. It's one where potential problems are identified and resolved before they become expensive problems during performance.

Make Sure Employees Understand Their Charge Codes

Once the project structure has been established, it needs to make sense to the people using it. Employees shouldn't simply receive a list of charge codes and be expected to figure out which one applies.

They need to understand what their assigned codes represent, which activities belong under each code, and what to do if they don't have an appropriate code available. This is especially important when a contract has multiple tasks, funding categories, locations, or other distinctions that affect how labor must be recorded.

Employees should also be able to explain their timekeeping practices if questioned during a DCAA floorcheck or other audit inquiry. That doesn't mean teaching scripted answers. It means making sure employees genuinely understand their assignments and accurately record the work they perform.

I once encountered a process where employees were locked out of their timekeeping system for an entire week when an option year was exercised because new charge codes had to be established. Aside from the administrative headache, consider the timekeeping and audit implications of employees being unable to record their time through the normal process.

A good project setup considers not only how employees will charge today, but how the structure will function when the contract changes tomorrow.

Explain the Why During Project Kickoff

While the structure should be planned and established before kickoff whenever possible, the kickoff is an important opportunity to explain it to the people responsible for executing the contract.

I recommend including at least one slide that walks through the project structure, explains what the different levels and charge codes represent, and identifies why those distinctions are necessary. If costs must be separated by location because the customer requires site-level reporting, tell the team that. If certain activities need to be tracked separately for billing or funding purposes, explain the reason.

Employees are much more likely to use a structure correctly when they understand what the information is being used for. The kickoff should also establish who employees contact when they have charging questions, need an additional code, or encounter a situation that doesn't fit the existing structure.

This is particularly important for Program Managers and supervisors, who may be responsible for reviewing time charges and helping employees understand how their work aligns with the project's requirements.

A project structure shouldn't be a mystery to the people responsible for using it.

Test the Setup and Maintain It Throughout Performance

Before widespread charging begins, take the time to test the setup. Confirm that employees can access the appropriate charge codes, that costs accumulate where expected, and that Accounting and Program Control can generate the information they'll need.

I also recommend documenting the important decisions made during setup. This doesn't require a lengthy procedure, but someone should be able to understand why the project was structured a particular way, what each level represents, and which contractual or reporting requirements drove those decisions.

And remember, project setup isn't necessarily finished once the first invoice goes out. Modifications, option years, new funding, changes in scope, and additional reporting requirements may all require adjustments. Those changes should be reviewed and coordinated before implementation whenever possible, rather than waiting until employees are unable to charge time or reports can no longer be produced.

A structure that worked perfectly at award may need to evolve as the contract changes. The objective is to manage those changes deliberately without disrupting performance or compromising the accuracy of the underlying accounting records.

Set It Up for the Entire Contract, Not Just the First Invoice

Project setup is one of those activities that doesn't always receive the attention it deserves. When it's done well, people may never notice. Employees charge their time correctly, invoices are generated, reports are available, and Program Management has the information needed to make decisions.

When it's done poorly, the consequences tend to appear months later, usually when someone needs information the system was never configured to capture. And that's when the spreadsheets start multiplying.

Whether your company uses Costpoint, Unanet, QuickBooks, or another accounting platform, the principle is the same: Understand the contract, understand your system, bring the right people into the conversation, and design the project structure around the information you'll actually need.

Because the best time to discover that your project setup won't work is before anyone starts charging to it.

Ally Compliance Solutions, LLC helps federal contractors strengthen contract administration, program control, and compliance processes, including project setup, financial reporting, and accounting system utilization.