R&E Expenses Under Section 174A

Research and experimental (R&E) expenses are costs paid or incurred in connection with developing or improving a product, process, formula, invention, software, or similar business component. They are the broader cost base your tax preparer reviews for research expense treatment, including deduction, capitalization, amortization, and election planning.

For software companies, R&E costs often include engineering wages, cloud infrastructure used for development and testing, software tools, contractor research work, prototype materials, and other costs tied to technical development.

Qualified Research Expenses (QREs) under Section 41 are the narrower costs used to calculate the federal R&D tax credit. Those expenses must connect to activities that satisfy the four-part test and fit the credit categories: qualifying wages, supplies, and eligible contract research.

R&E expenses under Section 174A can be broader than the credit calculation, but final tax treatment can depend on timing, location, elections, capitalization, and amortization rules. A cloud bill, SaaS tool, or contractor invoice may be relevant to R&E expense planning even when only part of it supports the stricter credit calculation. This is why quarryFi separates the R&E cost-base estimate from the Section 41 credit estimate.

quarryFi organizes R&E costs into structured records your accountant can review:

• Wage component: qualifying engineering time multiplied by salary-derived or hourly rates
• Cloud and infrastructure: AWS, Google Cloud, Azure, Cloudflare, Supabase, Vercel, Datadog, and similar vendors
• Developer tools: GitHub, Linear, Notion, Figma, Sentry, OpenAI, Anthropic, and other engineering platforms
• Contractors and supplies: vendor rows that may support research activity when tied to a project or technical objective

CSV imports are normalized into candidate rows and matched against vendor rules. quarryFi does not permanently retain the raw CSV. It keeps only accepted or needs-review structured expense records plus a permanent import audit record with filename, file size, row counts, SHA-256 hash, upload timestamp, and rule version.

The R&E expense page is meant to support review, not replace tax judgment. Your accountant can use it to reconcile engineering cost categories, decide which records belong in the R&E base, evaluate the Section 280C interaction, and determine how the final tax return should present deduction, capitalization, amortization, or credit treatment.

The strongest file is one that explains both the numbers and the source of the numbers: which vendors were included, which rows were ignored, which records needed review, and how the credit calculation differs from the broader R&E expense base.

Some expenses need more context before they can be treated confidently. A GitHub invoice for engineering repositories may be straightforward. A Notion or Linear charge could support R&E documentation when the workspace contains engineering specs, experiment notes, sprint records, or project evidence.

Future MCP integrations can enrich that project and evidence context from tools like Notion and Linear. The expense import flow is intentionally conservative today: it suggests likely R&E costs, asks for review when the vendor or purpose is ambiguous, and discards irrelevant rows instead of storing raw statements indefinitely.