An IT implementation phase acceptance report is one page long and looks like a formality. In fact, this document determines six issues at once: whether you can issue an invoice, when the VAT liability arose, when the statutory warranty period begins, whether you are in delay and contractual penalties are accruing, what has been deemed completed, and who bears the risk.
The supplier does not want to let it go because it cannot issue an invoice without the report. The customer does not want to sign because it believes that signing will prevent it from making warranty claims. The document sits around for weeks, the phase is complete, no one is paying — and no one knows when the relevant time limits begin to run.
This deadlock can be resolved with a single paragraph in the report. In this article, I will explain the legal effects of an IT implementation phase acceptance report, why signing it does not mean waiving claims, and give you two tools: a set of six clauses allowing acceptance with reservations and a four-date test that you can apply to the document sitting on your desk.
Before you begin — terms you need to know
Before we move on to specific clauses and risks, establish a common vocabulary. Acceptance reports use terms that sound similar but have different consequences.
| Term | What it means | Why it matters in the report |
|---|---|---|
| Material defect | A defect that prevents the system from being used for its intended purpose. There is no statutory definition — the contract should define it independently | Only a material defect entitles you to refuse acceptance. Refusal due to immaterial defects is unjustified |
| Immaterial defect | A fault that does not prevent the system from operating. It entitles you to accept with reservations and request a remedy | Recording an immaterial defect in the report does not prevent acceptance or invoicing |
| Statutory warranty | The contractor’s statutory liability for defects in the work (Article 638 § 1 in conjunction with Article 556 et seq. of the Civil Code). It applies regardless of whether the defect was visible on the acceptance date | Signing the report does not exhaust your statutory warranty rights — you may report defects after acceptance |
| Contractual penalties | An amount payable for breach of a non-monetary obligation (Article 483 § 1 of the Civil Code), without the need to prove loss | The date in the report translates directly into money — a penalty accrues for each day of delay |
| Acceptance-blocking / non-blocking comments | A classification of reservations in the report: acceptance-blocking comments prevent acceptance, while non-blocking comments allow the phase to be accepted with a list of faults to be remedied | No such distinction in the report = every comment may be treated as preventing acceptance |
Six consequences of a single signature on an acceptance report
An IT implementation phase acceptance report is not a receipt. It is a document that triggers consequences in six areas at once.
| No. | Effect | Legal basis | What this means for you |
|---|---|---|---|
| 1 | Remuneration becomes due | Article 642 § 1 and 2 of the Civil Code | From the acceptance date, the contractor is entitled to issue an invoice for the milestone |
| 2 | VAT tax point | Article 19a(2) of the VAT Act | The tax liability arises when the part of the service for which payment was specified is completed |
| 3 | Start of statutory and contractual warranty periods | Article 638 § 1 in conjunction with Article 556 of the Civil Code | The period during which you may report defects begins on the acceptance date |
| 4 | Delay and contractual penalties | Articles 476, 483–484 of the Civil Code | The date in the report determines whether the contractor is in delay — penalties accrue for each day, regardless of the amount of loss |
| 5 | Scope deemed completed | Contents of the report + contract | The report specifies which modules and integrations have been accepted — no itemised list = an evidentiary dispute |
| 6 | Limitation period for claims | Article 646 of the Civil Code | Claims under a contract for specific work become time-barred 2 years after the work is delivered — the date in the report starts the clock |
In judgment V CSK 544/12, the Supreme Court held that defects justifying refusal of acceptance are those that render the work unfit for ordinary use or are clearly inconsistent with the contract (Source: Supreme Court judgment IV CSK 610/13). In judgment I AGa 216/22, the Court of Appeal confirmed this position — where defects are immaterial, the customer should accept the work and exercise its statutory warranty rights (Source: Court of Appeal judgment I AGa 216/22).
Conclusion: refusing acceptance due to immaterial defects is not caution — it is a risk. A customer that refuses to sign the report because of minor faults risks having the remuneration deemed due despite the absence of a signature. The safe approach is to accept with reservations.
Why signing the report does not mean waiving claims
This is the most common reason why reports sit around for weeks. The customer fears that signing will prevent it from making warranty claims. The contractor does not issue an invoice because it has no signed document. The project stalls.
This fear stems from a misunderstanding. An acceptance report is a statement of knowledge about the status of the work — not a declaration of intent to waive claims. The statutory warranty for defects in the work (Article 638 § 1 in conjunction with Article 556 et seq. of the Civil Code) applies regardless of whether the defect was visible on the acceptance date, provided that the customer was unaware of it at the time.
The problem arises when the report includes wording such as “the parties have no reservations whatsoever". Although this is usually intended to confirm that there are no comments at that particular time, it may later be interpreted as a waiver of claims (Article 65 § 2 of the Civil Code — interpretation of declarations of intent).
What to do about it:
- Delete all wording from the report stating that there are no reservations whatsoever
- Replace it with a classification of the deficiencies as immaterial within the meaning of the specified contractual provision
- Add a non-exhaustion-of-rights clause stating that acceptance does not confirm completeness or compliance with the pre-implementation analysis documentation and does not restrict the right to report defects
The paradox is that a clause which appears to be “drafted against the contractor" is precisely what unlocks its invoice. The customer will accept it because it feels comfortable signing. The contractor will accept it because it triggers payment.
Six clauses that enable acceptance with reservations
Below is a set of provisions that make it possible to sign the report without exhausting your rights. Each addresses a specific risk.
1. Distinguishing between acceptance-blocking and non-blocking comments
Introduce two categories of reservations into the report. Acceptance-blocking comments prevent acceptance — they concern material defects. Non-blocking comments allow the phase to be accepted with a list of faults to be remedied.
Link the category to a specific contractual provision defining a material defect. Do not stop at the general word “material" — without a reference to the contract, each party will interpret it differently.
2. Remedial period calculated from the date the report is signed
Replace all fixed remedial deadlines with periods calculated in business days from the date of signing the report. The document circulates between the parties — a fixed date may have already passed before both parties sign.
Signing a template containing a fixed remedial deadline that has already passed = placing yourself in delay and triggering contractual penalties.
3. Deferring verification to subsequent milestones
Add a clause deferring verification of the configured modules’ operation to subsequent phases (training, testing, data migration, parallel operations). Comments arising from such verification are handled under the contractual complaints procedure and do not constitute reservations concerning the phase being accepted.
Without this clause, every defect reported later may be used as an argument that the phase should not have been accepted.
4. Reservation concerning standard product limitations
Some of the customer’s configuration needs may be impossible to meet through no fault of the contractor, but because of limitations in the manufacturer’s standard product. Describe this in the report in three parts:
- It is not a defect
- It is not a reservation concerning acceptance
- It is not the customer’s abandonment of the requirement — the matter will be revisited when the manufacturer makes the feature available
This clause protects both parties, so it is the easiest to negotiate.
5. Non-exhaustion-of-rights clause
Acceptance does not confirm completeness, correctness or compliance with the pre-implementation analysis documentation and does not restrict the right to report defects. Formally, this duplicates the statutory warranty. But it unlocks the other party’s signature and your invoice.
6. Exhaustive itemisation of the scope
Describe the subject matter of acceptance by listing the functional areas (finance, fixed assets, sales, KSeF, document workflow, HR and payroll, time tracking, analytics) and add “as well as integrations between the individual modules".
A report merely stating “Phase 2 accepted" is useless as evidence of scope. A report listing modules and integrations resolves the most common dispute in implementation projects.
The four-date test — apply it to every report
A single acceptance report form contains four different dates. A common practice is to enter the document preparation date in every field. This is a costly mistake.
| No. | Date | What it means | What it is used for | Typical mistake |
|---|---|---|---|---|
| 1 | Work completion date | The day on which the contractor actually completed work on the phase | Determining whether the contractor met the schedule | Entering the report preparation date instead of the actual completion date |
| 2 | Date the work was submitted for acceptance | The date of delivery of the work within the meaning of Article 643 of the Civil Code | Start of the customer’s contractual period for carrying out acceptance activities | Treating it as the same as the report preparation date — this eliminates the contractor’s entire time allowance for acceptance activities |
| 3 | Acceptance date | The day on which the customer confirms acceptance of the phase | Start of statutory and contractual warranty periods; usually the service completion date for VAT purposes | Confusing it with the signing date — if these dates differ, there is a risk of using the wrong tax point |
| 4 | Date the report is signed | The day on which both parties sign | Recommended reference point for remedial periods | Treating it as the acceptance date when the document circulated for weeks before being signed |
How to carry out the test:
- Enter each of the four dates separately — do not copy one date into every field
- Check the submission date against the schedule and the signed appendix to the contract
- Compare the acceptance date with the invoice date — a discrepancy = a risk of incorrectly identifying when the tax liability arose
- Make sure that remedial periods run from the signing date, not from a fixed calendar date
General Interpretation No. DD3/033/101/CRS/13/RWPD-48186/RD issued by the Minister of Finance states that a partial service is completed when the work is actually completed and submitted for acceptance — not merely when the report is signed (Source: General Interpretation of the Minister of Finance). If the report merely documents work completed earlier, the date on which it is signed does not automatically defer the tax point.
It is worth remembering that tax legislation does not contain stand-alone definitions of terms such as licence, work or computer program. Whether a supply is classified as a supply of goods or services depends on the interpretation of tax authorities and administrative courts. Hardware constitutes a supply of goods, while implementation and configuration constitute a supply of services. This classification directly affects when the tax liability arises.
IT implementation acceptance reports and construction contract templates
If you receive a report template from a counterparty containing fields for a construction log, quantity survey and land survey documentation — it is not a mistake. It is a construction template that someone copied into an IT project.
In judgment V CSK 150/07, the Supreme Court classified a contract covering the supply, installation and commissioning of software as a mixed contract predominantly comprising elements of a contract for specific work (Source: Supreme Court judgment V CSK 150/07). The statutory basis for acceptance of an implementation is Article 643 of the Civil Code (contract for specific work), not Article 647 of the Civil Code (construction work).
Construction case law may serve as an interpretative argument, but it does not apply automatically. There is no established line of case law accepting a general analogy between the acceptance of construction work and the acceptance of an IT implementation (Source: Civil Code – consolidated text).
What to remove from a construction template:
- Delete fields irrelevant to an IT implementation (construction log, quantity survey, land survey documentation)
- Trim the settlement document checklist to items that actually exist — usually the pre-implementation analysis documentation plus the contract and its appendices
- Retain the distinction between acceptance-blocking and non-blocking comments — this is one construction that does work in IT
- Add a field listing modules and integrations — construction templates do not have one because they deal with a physical rather than functional scope
Contractual penalties — how the date in the report translates into money
A contractual penalty is payable regardless of the amount of loss (Article 484 § 1 of the Civil Code). The date entered in the report translates directly into the amount of penalties — a penalty accrues for every day of delay, regardless of whether the customer has suffered any loss.
Rates observed in judgments of the National Appeals Chamber:
| Case | Daily rate | Comments |
|---|---|---|
| KIO 2128/15 | 0.02% of the maximum contract value per business day | A low rate, but calculated on the entire contract value |
| KIO (from research findings) | 0.4% of the net remuneration for the phase for each day of delay | Calculated on the phase value — a safer structure |
| KIO 823/19 | PLN 70,000 per day of delay | No data on the contract value — percentage conversion impossible |
(Source: KIO judgment – 0.4% penalty) | (Source: KIO 823/19)
These are examples from specific proceedings, not statistical market data. There is no statutory or official percentage cap on penalties for IT implementations. A safer structure is to calculate the penalty based on the remuneration for the delayed phase rather than the total contract value, with a contractual aggregate cap on all penalties.
A court may reduce a grossly excessive penalty (Article 484 § 2 of the Civil Code), but calculating the penalty on the entire contract value for a delay in one module increases the risk of such a finding.
How to define a material defect in an implementation contract
Article 560 § 4 of the Civil Code states that the buyer may not withdraw from the contract if the defect is immaterial — but it does not define the criteria for materiality (Source: Article 560 of the Civil Code – consolidated text). A contractual “material defect" is not identical to the Civil Code concept — which is why the implementation contract should define it independently.
A proven P1–P4 classification used in implementation contracts:
| Priority | Name | Description | Impact on acceptance |
|---|---|---|---|
| P1 | Blocking | The system or module does not start, data is corrupted, and no workaround is available | Acceptance-blocking comment — prevents acceptance |
| P2 | Major | A business function does not work correctly, but a workaround is available | Non-blocking comment — acceptance with a reservation and remedial deadline |
| P3 | Standard | A fault affecting ease of use but not the outcome | Non-blocking comment — remedy as part of maintenance |
| P4 | Cosmetic | A visual imperfection or typo in the interface | Non-blocking comment — remedy in the next update |
This classification is a contractual practice, not a statutory standard. Link it to response and resolution times (SLA) to avoid disputes about how quickly the contractor must respond to a report of a given priority.
When defining the scope of the phase being accepted, it is also worth clearly distinguishing maintenance from functional development. If the contract does not specify whether subscription fees cover maintenance, development or both — a dispute will arise at acceptance over what is included in the milestone.
Acceptance and the transfer of copyright — a separate mechanism
Signing an acceptance report alone does not transfer copyright if the contract does not expressly provide that rights are transferred at that time and does not list the fields of exploitation. Article 41(2) of the Copyright Act provides that an agreement transferring rights covers the expressly listed fields of exploitation, while Article 53 requires written form under pain of nullity (Source: Copyright Act – consolidated text).
The contract should separately govern:
- The time of phase acceptance (report)
- The time of copyright transfer (which may, but does not have to, coincide with acceptance)
- The scope of the transfer — source code, documentation, configurations, graphic elements
- The status of open-source components
- Rules concerning derivative rights (adaptations)
For implementations accepted in phases, it is particularly important to determine whether rights are transferred with each partial report or only upon final acceptance. The absence of provisions in this area leaves an obvious gap.
18-point acceptance report checklist
Before signing a report — whether your own or one received from a counterparty — go through this checklist.
| No. | Checkpoint | What to look for |
|---|---|---|
| 1 | Origin of the template | Is it a construction template? If so — trim it |
| 2 | Itemised scope | Does the report list the modules, not just the phase number? |
| 3 | Integrations | Has “as well as integrations between the modules" been added? |
| 4 | Acceptance-blocking / non-blocking comments | Is there a distinction and a reference to the contractual definition of a material defect? |
| 5 | Definition of a material defect | Does the contract define a material defect using the P1–P4 classification? |
| 6 | Remedial period | Is it calculated from the signing date rather than a fixed date? |
| 7 | Complaints procedure | Are comments from subsequent phases handled under the complaints procedure rather than as reservations concerning acceptance? |
| 8 | Non-exhaustion-of-rights clause | Does acceptance neither confirm completeness nor restrict the right to report defects? |
| 9 | Four dates | Have the following been entered separately: work completion, submission for acceptance, acceptance, and signing? |
| 10 | Consistency of the submission date with the schedule | Does the submission date correspond to the actual completion of the work? |
| 11 | Consistency of the acceptance date with the invoice date | Is there any discrepancy creating a VAT risk? |
| 12 | Basis for invoicing | Does the report provide the basis for issuing an invoice with reference to the relevant contractual provision? |
| 13 | Consistency of amounts | Does the amount in the report correspond to the amount in the payment schedule? |
| 14 | Document checklist | Has it been trimmed to include only items relevant to the IT implementation? |
| 15 | Complete acceptance committee | Will authorised individuals from both parties sign? |
| 16 | Standard product limitations | Have they been described in three parts: not a defect, not a reservation, and not abandonment? |
| 17 | Copyright | Does the contract govern the time of transfer separately from acceptance? |
| 18 | Licence subscription date | Does the subscription period run from the date of purchase from the manufacturer rather than the invoice date? |
Public procurement — additional restrictions on ERP implementations
If the customer is a public entity or municipally owned company, the acceptance report is subject to additional requirements under the Public Procurement Law. Article 433 of the Public Procurement Law restricts impermissible contractual provisions, while Article 436 specifies mandatory contractual elements concerning penalties (Source: Consolidated text of the 2024 Public Procurement Law).
The Public Procurement Law does not establish a single mandatory acceptance report template for ERP implementations. Acceptance clauses, the defect catalogue, acceptance tests and the consequences of refusal must be clearly regulated in the procurement documents. Sample contracts from the Public Procurement Office’s miniPortal provide for penalties of 0.5% of the remuneration for each day of delay and 20% for withdrawal for reasons attributable to the contractor — but these are provisions of specific templates, not laws establishing a universal cap (Source: Public Procurement Office contract template).
In public procurement, the ability to modify the report template may be limited — but even then, it is worth negotiating a distinction between acceptance-blocking and non-blocking comments and remedial periods calculated from the signing date.
Build your own template instead of correcting someone else’s
Every report received from a counterparty requires legal review before it is signed. But correcting someone else’s templates from scratch every time is a waste of time and money.
A better approach is to build your own standard phase acceptance report template and adopt a rule that templates received from counterparties are always reviewed with comments explaining the basis for each amendment.
Just as with the verification checklist used when signing an IT contract — where the review covers alignment of the scope with requirements, regulation of IP rights, measurable SLAs and exit mechanisms — an acceptance report should undergo a formal “close-out review" before it is signed.
Train the implementation team and PMO on the principle that a report is a statement of knowledge about the status of the work, not confirmation that it is free of defects — and that refusal of acceptance due to immaterial defects is unjustified.
IT phase acceptance report — legal support for implementation projects
The acceptance report is where a project’s financial, legal and relationship risks converge. A poorly drafted document blocks invoicing, triggers penalties and opens disputes over scope.
Sawaryn & Partners advises on IT and AI system implementations — from reviewing acceptance documents and material defect clauses, through standardising templates across an entire project portfolio, to handling disputes over milestone acceptance.
Three engagement options:
| Option | Scope | Who it is for |
|---|---|---|
| Operational minimum | One-off review of a report before signing, with comments and recommendations | A supplier or customer with one report to sign |
| Solid foundation | A bespoke report template plus a checklist for the implementation team | An implementation company running several projects in parallel |
| Comprehensive protection | Audit of the entire acceptance process and consistency between the contract, schedule, report and invoice | An IT integrator or customer preparing for a major ERP implementation |
If you have an acceptance report waiting on your desk for signature — or if you want to organise the acceptance process across your entire project portfolio — contact us.
Summary — what to remember about an IT implementation phase acceptance report
An IT implementation phase acceptance report is not a box-ticking formality. It is a document that determines invoicing, the tax point, statutory warranty rights, contractual penalties, the scope of completion and the limitation period for claims.
Signing does not mean waiving warranty claims — provided that the report contains the appropriate clauses. The six provisions described in this article allow a phase to be accepted with comments without losing the right to report defects. The four-date test protects against inconsistent deadlines and an incorrectly identified tax point.
Before you sign your next report — put it through the 18-point checklist. And if you need support reviewing acceptance documents or standardising templates — contact us.
Frequently asked questions
Does signing a phase acceptance report mean that I lose the right to make claims concerning defects?
No. The statutory warranty for defects in the work (Article 638 § 1 in conjunction with Article 556 et seq. of the Civil Code) applies regardless of whether the defect was visible on the acceptance date. Signing the report is a statement of knowledge about the status of the work, not a waiver of claims. The risk arises when the report contains wording such as “the parties have no reservations whatsoever" — the other party may then try to interpret it as a waiver. Delete such wording and replace it with a non-exhaustion-of-rights clause.
Can the customer refuse to accept a phase if several things do not work perfectly?
It depends on the nature of the defects. Refusal is justified only in the case of material defects — those that prevent the system from being used for its intended purpose. In the case of immaterial defects, the customer should accept the phase with reservations and request a remedy. Unjustified refusal of acceptance constitutes creditor delay (Article 476 of the Civil Code) — it does not trigger penalties against the contractor and may hinder the customer’s own claims.
Which date should be entered in the report as the service completion date for VAT purposes?
According to the general interpretation issued by the Minister of Finance, a partial service is completed when the work is actually completed and submitted for acceptance — not merely when the report is signed. If the contract makes acceptance of the phase conditional on signing the report, the report becomes important evidence. Enter the four dates separately: work completion, submission for acceptance, acceptance and signing — and compare the acceptance date with the invoice date to avoid discrepancies.
What should I do when a counterparty sends its own report template and says “it’s just a formality, sign it"?
Do not sign it without a review. Check the origin of the template (is it a construction template?), put it through the 18-point checklist, verify the four dates and make sure it distinguishes between acceptance-blocking and non-blocking comments. Templates received from counterparties should undergo legal review, with comments explaining the basis for each proposed amendment.
How long do I have to pursue implementation claims if a dispute arises several years into the project?
Claims under a contract for specific work become time-barred 2 years after the work is delivered (Article 646 of the Civil Code). The date in the acceptance report starts this clock. For implementations carried out in phases, each partial report starts a separate limitation period for claims concerning that phase. This is why the acceptance date in the report directly affects how long you have to pursue claims.
Is it worth having my own acceptance report template, or is it enough to correct counterparties’ templates?
It is worth having your own template. Correcting someone else’s templates from scratch every time wastes time and increases the risk of omitting important elements. A standard template prepared once and tailored to the specifics of IT implementations allows the implementation team to work according to consistent rules. Treat templates received from counterparties as a starting point for negotiation, not as documents ready to be signed.
