R&D and design work ties the use of incentives and deductions to a correct classification of spend and to documentation that starts with the project, not after it. In many companies invoices and payroll are collected once the project is over. That order falls apart in an inspection. First the novelty claim of the technical activity is written, then staff, bought-in services, depreciation and overhead allocation. Otherwise the deduction looks like an accounting shortcut. The aim is a file that can be defended before the authority and that also makes internal project tracking easier.

The service is for manufacturers that use a technology centre, a design centre, a technopark or project-based support, for software and engineering firms, for mould and industrial-design teams, and for groups that invoice intra-group R&D. The shared problem is the same: routine production and development are tangled, time is not written and support staff are overstated. The audience is not only the tax unit. The technical team, human resources and finance must speak the same project code. If they do not, the incentive becomes a year-end correction fight.

We start with the project card, the technical description, the staff list, time records, bought-in service contracts and the chart of accounts. Which work is R&D, which is design and which is ordinary production or sales support is separated. That split is built from the output and the document, not from an engineer's sentence. Market research, quality control and small customer-specific changes are often outside the incentive. That fact is written at the start. If it is not, the file later becomes a “we included everyone” defence.

Cost testing runs line by line. Actual duties in payroll, laboratory or workshop records, purchasing and the depreciation key are read against one another. Overhead is not allocated with an unexplained percentage. In bought-in services, intellectual property, delivery and confidentiality clauses are reviewed. For related-party services, the price and the actual contribution are examined separately. Missing papers, late technical reports and back-dated time entries form a risk list of their own. Rumour is not inspection evidence.

The deliverable is a periodic deduction and support file, staff and spend reconciliations, a technical-to-finance bridge table and a short risk note for management. If asked, the centre application, the annual activity report and an inspection defence are produced in the same order. The text uses the organisation's own project and product names. The file can then speak in the same language when the authority asks. A “we use the incentive” sentence that stays on the shelf is not a deliverable. The deliverable is the document.

Intellectual property and intra-group sharing are the unseen tax of this heading. If a patent, know-how or software right sits in another company, spend and income may not meet in the same place. Transfer pricing, disguised profit and VAT are read in the same file. We do not isolate the incentive as a corporate-tax deduction only. A right that sits in the wrong place breaks both the incentive and the arm's-length price. Management still decides. The assumption is not hidden.

The people side decides more files than the technology does. If the same engineer covers both a line stoppage and development, a time record is required. Without a record, allocation is an estimate. An estimate is the first piece to fall in an inspection. If training, the time application and the date on which a project code will be closed are not discussed early, staff return to the old habit. We do not leave that resistance as “engineers will not write”. Workload and a simple daily rhythm are put inside the plan.

Timing should follow project start, the support application and the period-end return. A card built after the spend has already occurred is often incomplete. An early start locks the technical description and the finance code at the same time. A late start may do little more than label existing invoices. Our communication model is a short quarterly check and a written warning on critical spend. Surprise may belong to the inspection. It should not belong to the file.

Support types can break one another. If the same spend is put through a deduction, a grant account and a withholding incentive, the risk of double benefit is written down. If it is not, the authority later argues about the whole. We present options as legal risk, cash effect and operating burden. An aggressive reading reduces tax in the short run and becomes more expensive in inspection. A defensible reading is what makes the incentive last.

In short, R&D and design work exists to keep the technical fact, the spend fact and the legal boundary in the same file. We do not aim to make the organisation write a larger deduction. We aim to help it carry the deduction it writes. An independent view may be less glossy than a support brochure. It produces fewer surprises on inspection day. What we leave is not a rate, but a project file that can be repeated. The file is kept simple enough to be updated in the same language the next year.