Neo.Tax

Neo.Tax is specialised software for R&D tax-credit and software-capitalization workflows. Neo.Tax says it ingests project-management, payroll, ledger, organisation, and engineering-system data; its six named agents create project groupings, apply an IRS qualification test, quantify work, calculate qualified research expenses (QREs), create project narratives, and defend QREs. The listed deliverables are an R&D tax-credit study plus ASC 350-40 and Section 174 outputs. [S1]

These outputs can affect a tax provision, credit claim, or audit response. The useful test is traceability: can the team reproduce each conclusion from contemporaneous records, catch missing data, and correct the work before a tax professional signs off? [S1][S2][S3]

Best for: US enterprise tax teams with a meaningful engineering footprint, available project and payroll data, accountable tax and engineering reviewers, and a controlled way to compare output with a historical or parallel process.

Not for: A team seeking general tax research or client-advisory writing; a business without trustworthy project, payroll, vendor, or financial data; or a buyer that cannot staff tax review, evidence sampling, exception handling, and final filing authority.

Identify candidate R&D projects

• Trigger: A historical review, periodic R&D-credit cycle, or new engineering data arrives.
• Inputs: Project-management tickets, content, hierarchy, and available organisation context from systems such as Jira, Linear, or Azure DevOps. [S1][S2]
• Output: Project groupings classified as qualified, partially qualified, or unqualified against the IRS four-part test, according to Neo.Tax's description. [S2]
• Human checkpoint: A tax professional and relevant engineering owner sample the groupings, inspect the cited source data and rationale, and resolve ambiguous or novel work.
• Success measure: Qualified-project precision/recall on an agreed sample, reviewer-override rate, missing-data rate, and time from data cut to reviewed project list.

Quantify eligible work and expenses

• Trigger: Reviewed project groupings move to calculation.
• Inputs: Qualified projects, project records, payroll, vendor, and financial data. [S1][S2]
• Output: Employee R&D percentages and QRE calculations, with any unrecorded time flagged for the filer as described by Neo.Tax. [S2]
• Human checkpoint: Tax and finance owners reconcile employee, vendor, and expense results to the buyer's records; they approve treatment for exceptions and material variances.
• Success measure: Calculation variance versus a controlled baseline, reconciliation breaks, reviewer adjustments, exception age, and evidence completeness.

Prepare an R&D-credit evidence package

• Trigger: The reviewed calculation needs documentation for a provision, credit claim, or audit response.
• Inputs: Reviewed project decisions, calculations, and underlying contemporaneous records. [S1][S2]
• Output: Neo.Tax says it generates project narratives and an R&D tax-credit study. [S1][S2]
• Human checkpoint: The accountable tax professional checks legal and factual conclusions, document completeness, source traceability, and the final filing or provision position.
• Success measure: Time to review, unresolved audit questions, traceability coverage, correction rate, and rework after reviewer or auditor feedback.

1. The buyer defines the tax year, legal entities, credit scope, source systems, data owner, accounting and tax policies, exception conditions, and signing authority.
2. Neo.Tax ingests the agreed project, engineering, payroll, vendor, financial, and organisation data. The vendor lists several systems, but a public source does not prove a particular buyer's connector or permissions. [S1][S2]
3. Neo.Tax says its agents group work into projects, classify project groupings, calculate percentages and QREs, and create narratives and tax outputs. [S1][S2]
4. Tax, finance, and engineering reviewers inspect the supporting records, reasoning trail, calculation changes, and missing-data flags; they resolve exceptions before a conclusion reaches the return, provision, or audit package. [S2][S3]
5. The buyer retains the exportable evidence, compares results with the baseline, controls updates to data mappings or policy logic, and has a documented correction and exit path.

The trade-off is between lower manual interviewing effort and a stronger need for evidence governance. A model can sort a large set of contemporaneous records, but it cannot establish the buyer's legal position or data completeness by itself. The buyer should judge the workflow by traceability, correction, and review performance, rather than by a polished narrative alone. [S2][S3]

Verified facts

• Neo.Tax describes software for R&D-tax and software-capitalization workflows with R&D tax-credit study, ASC 350-40, and Section 174 outputs. [S1]
• The vendor describes six agents covering project creation, IRS qualification, quantification, QRE calculation, project narrative, and QRE defence. [S1]
• Neo.Tax says it uses project-management, payroll, vendor, and financial data; its technical description says it groups tickets, applies the four-part test, generates narratives, calculates employee percentages, and flags unrecorded time. [S2]
• Neo.Tax's security page states that customer-specific training use is optional, and that its models operate on ticket metadata plus names and descriptions rather than source code, birth dates, social-security numbers, or employee addresses. [S3]

Vendor claims

• Neo.Tax says its workflow eliminates surveys and interviews and produces audit-ready outputs. Validate this against the buyer's data quality, auditor expectations, and tax-review process. [S1]
• In a vendor-published Mercury story, Neo.Tax attributes an approximately 10% R&D-credit increase and less than one hour of total engineering time to that customer deployment. This is a customer story, not a general outcome guarantee. [S4]
• Neo.Tax states that every decision includes a reasoning trace and is traceable, replicable, and reviewable by tax professionals. Inspect this directly in a buyer-specific pilot and determine whether the export meets the buyer's workpaper and audit needs. [S3]

B2Bagents assessment

Neo.Tax is a suitable tax-advisory candidate because the vendor describes a concrete, multi-step R&D-credit workflow with inputs, calculations, evidence production, and named outputs. It is not a substitute for tax judgment. The strongest first deployment is a historical, read-and-compare project where the buyer tests project classification, source traceability, expense calculation, missing-data handling, and reviewer intervention before relying on an output in a return or provision. [S1][S2][S3]

Material unknowns

• Public commercial terms, pricing unit, implementation fees, minimum commitment, renewal, cancellation, service levels, and exit assistance.
• The buyer's exact integrations, source-field mapping, data freshness, ingestion schedule, read/write permissions, audit-log export, and correction path.
• Performance, accuracy, and outcome evidence for the buyer's industry, legal entities, project-tracking habits, payroll data, and tax position.
• Buyer-specific scope for SOC 2 and ISO evidence, data-processing terms, model providers, subprocessors, retention/deletion, residency, support access, incident commitments, and dedicated-tenancy options.

Good-fit conditions: Stable project-management and payroll data, a meaningful R&D population, an existing close or tax-workpaper process, agreed legal-entity and evidence scope, tax and engineering reviewers, and willingness to run a historical reconciliation before production use.

Poor-fit conditions: Material work is not represented in the source systems; project tickets are sparse or misleading; payroll and financial data cannot be reconciled; data ownership is unclear; or no tax professional can test and approve the final position.

Predictable failure modes and controls:

• A ticket grouping may miss or misclassify work. Use a labelled historical sample, include qualified, partially qualified, unqualified, unclear, and reorganised work, and track reviewer overrides. [S2]
• Missing or late source data can produce misleading employee percentages or QREs. Reconcile source-system completeness, direct flagged records to tax and engineering owners, and stop the workflow when defined completeness thresholds fail. [S2]
• A traceable output can still be legally or factually wrong for the buyer. Keep tax interpretation, materiality thresholds, and filing sign-off with an accountable tax professional. [S2][S3]
• Public security statements do not establish contract coverage for the buyer's data. Complete security, privacy, model-use, access, and deletion diligence before transferring production data. [S3]

Begin with one completed tax year or a representative business unit. Name a tax executive as sponsor, a tax professional as final conclusion owner, an engineering-data owner, a payroll or finance reconciliation owner, a security owner, and an integration owner. Freeze the baseline: projects reviewed, time spent on interviews and workpapers, evidence gaps, calculation variance, reviewer overrides, and audit questions.

Neo.Tax lists Jira, Linear, Workday, payroll, ledger, Confluence, Oracle NetSuite, GitHub, ADP, and Azure, and describes use of project, payroll, vendor, and financial data. [S1][S2] Before production data is connected, review connector availability, fields, identity and role mapping, import cadence, source preservation, late or deleted record handling, retries, audit-log export, error queues, data removal, and the path to recreate a completed study without the vendor.

Define a narrow acceptance boundary: project classification and evidence aggregation first, followed by calculation reconciliation and narrative review. Do not use an output for a return, provision, or audit response until the agreed sampling, reconciliation, exception, and tax-sign-off conditions pass.

Neo.Tax publicly states that it maintains SOC 2 Type II and ISO/IEC 27001:2022 evidence. Its security page describes PostgreSQL on Neon and Google Cloud Storage, customer-specific logical data separation, U.S. data locations for the stated environments, TLS 1.3/AES-256 encryption, RBAC, MFA, SSO, and optional dedicated tenant arrangements. It also says customer data used for training or fine-tuning can be opted out, and describes its stated input limits. These are vendor statements; ask for current reports, scope, exceptions, architecture, and binding contract terms. [S3]

The relevant governance control is evidence accountability, not merely access security. Log source-system versions and data cuts; preserve the basis for project, employee, and expense decisions; name the reviewer for every material override; approve tax-logic or integration changes; and test export, correction, and deletion procedures. A buyer should also request the DPA, subprocessor and model-provider list, retention, residency, support access, breach commitments, security whitepaper, model-training setting, and termination process. [S3]

Neo.Tax's public homepage invites a demo and does not state a public price or pricing unit. [S1] Request whether charges are per legal entity, employee, project, study, tax year, data volume, integration, user, environment, software-capitalization module, implementation phase, support tier, or managed service. Obtain usage limits, overages, pilot-to-production conversion, renewal, data export, termination assistance, and responsibility for tax work or tax opinions.

Budget a pilot as an operating change: include source-data preparation, integration, tax and engineering sampling, finance reconciliation, evidence review, security diligence, change management, and capacity to correct the completed workpapers.

Use a historical year or one business unit before a live filing deadline. Include well-documented, sparse, contradictory, newly created, reorganised, partially qualified, unqualified, and missing-data records. Require reviewers to work from a blinded or independent baseline where feasible.

Measure source-data completeness, project-classification precision and recall, employee-percentage and QRE variance, reviewer-override rate, missing-data exceptions, explanation traceability, workpaper completeness, time from data cut to signed review, tax and engineering hours, audit-question rate, and reproducibility after a source correction. Segment results by legal entity, team, product line, record quality, employee type, and exception reason.

Set stop conditions before activation: pause if a material calculation cannot be traced to its source, a qualification conflict cannot be resolved, source completeness falls below the agreed threshold, a reviewer cannot reproduce an output, an integration maps data incorrectly, security evidence is unavailable, or the accountable tax professional declines to sign off.

Compare specialised R&D-credit products on the operating model, not on generic AI claims: contemporaneous data coverage, project grouping and qualification method, evidence traceability, payroll and QRE reconciliation, reviewer workflow, software-capitalization coverage, implementation scope, security terms, support, pricing unit, and exit path. Tax-research copilots are only adjacent alternatives: they help professionals find and draft answers but do not necessarily assemble a credit study from engineering and financial records.

1. Which exact data fields drive project qualification, employee percentages, QRE calculations, and narratives? Request a source-to-output mapping and reproduce it on a representative sample. [S1][S2]
2. Where does a tax professional review, override, or correct the workflow? Obtain the approval, exception, reasoning-trace, audit-log, and final sign-off design for the buyer's configuration. [S2][S3]
3. How will we detect project data that is incomplete or inconsistent? Test missing, late, contradictory, and reorganised tickets and inspect the flag, resolution owner, and effect on the calculation. [S2]
4. What does the commercial and security contract actually cover? Request current pricing, implementation scope, assurance reports, DPA, model and subprocessor details, retention, residency, access, incident, export, and termination terms. [S3]
5. How will we prove the result improves the current process? Agree on a historical baseline, sample design, reconciliation, reviewer criteria, evidence-completeness threshold, and stop conditions before the pilot.