A component is not simply a department or job code.
IRC §41(d)(2)(B) identifies products, processes, computer software, techniques, formulas, and inventions held for sale, lease, license, or use in the taxpayer's business. A component therefore need not be a physical item sold to a customer.
A project code can help locate records, but it may cover several development efforts or mix technical work with other activities. Explain what was being developed before deciding how the study should organize the work.
If your project list does not map neatly to business components, call Paribus to discuss a practical starting point.
What product, process, or software were you developing?
A manufacturer might work on a new product and separately develop a process for producing it. A software business might track a large release containing distinct development efforts. An engineering firm might have a customer contract covering several technical tasks.
In each case, ask what the development subject is, which technical uncertainties relate to it, and which records explain the investigation. Do not assume that one invoice, one customer, or one annual budget automatically equals one component.
For an illustrative filling-line project, distinguish the equipment design question from scheduling changes, operator training, and routine installation. The relevant study boundary should follow the facts, not the desire to place every cost under a single qualifying label.
How should you divide projects into components?
A description covering the entire business can obscure which activities meet the requirements. On the other hand, splitting every task into a separate component without a factual basis can make the study difficult to follow.
The regulations include a shrinking-back rule for examining qualifying subsets when the requirements are not met at the overall component level (Treas. Reg. §1.41-4(b)(2)). This is a specific analytical rule, not a reason to divide a project randomly or assume every smaller task qualifies.
Discuss the project's structure and development sequence with the technical team. Preserve an explanation of the boundaries used so your accountant can understand how the study reached its conclusions.
We can discuss your projects, the supporting records, and the component questions that need to be resolved before the expense schedules are finalized.
Match each component to its records and expenses.
- A stable name or identifier for the development subject.
- The intended function or improvement.
- The technical questions and evaluated approaches.
- The people, periods, and records involved.
- The expense schedules associated with the reviewed work.
Keep this map consistent across interviews, workpapers, and the final package. If names change between engineering and accounting systems, record the connection. Otherwise, a reviewer may not know that two differently named files concern the same work.
Where Form 6765 component reporting applies, the underlying record can support preparation of that information. Our Section G guide discusses reporting separately; organizing components does not by itself determine a taxpayer's reporting obligations.
Start with your existing project list.
You do not need to reorganize every internal system before calling. Bring a description of how your team tracks projects and where the technical and cost records are stored. Identify broad codes that combine several types of work.
Paribus Advisors prepares activity evaluations, QRE schedules, credit calculations, and supporting study packages. We can work with your accountant to organize the study and agree on the documents they need.