Accepting an IT Implementation Phase in Poland: What the Sign-Off Report Really Does

Accepting an IT Implementation Phase in Poland: What the Sign-Off Report Really Does

A one-page acceptance report for an IT implementation phase may look like an administrative formality. Under a Polish-law contract, it can affect six issues at once: when the supplier can invoice, when a Polish VAT obligation arises, when defect-liability periods begin, whether delay penalties accrue, what work has been accepted, and when the limitation period for claims starts.

This creates a familiar deadlock. The supplier wants a signed report so it can invoice. The customer hesitates because it fears that signing will prevent later defect claims. The completed phase remains unpaid while the relevant dates become harder to establish.

The answer is not necessarily to sign without comment or refuse acceptance. A report can record acceptance with reservations: it confirms which phase has been accepted, identifies defects that still need attention, and preserves the customer’s ability to report further defects. This article sets out six provisions to consider, a four-date test, and an 18-point checklist.

Polish terms that matter at acceptance

The distinctions below should also be reflected in the contract. In particular, the contract should define which defects block acceptance.

Six consequences of signing an acceptance report

An acceptance report is more than a receipt for completed work. Read it alongside the contract, payment schedule, defect provisions, and invoicing arrangements.

The Polish Supreme Court has addressed the distinction between defects that justify refusing acceptance and those that do not. The approved source refers to judgment V CSK 544/12 while linking to a document labeled IV CSK 610/13; the proposition stated there is that refusal may be justified where defects make the work unfit for ordinary use or clearly inconsistent with the contract (linked Supreme Court judgment). A Court of Appeal judgment, I AGa 216/22, states that where defects are immaterial, the customer should accept the work and use its statutory defect remedies (Court of Appeal judgment).

The practical point is significant for both parties. Refusing to sign solely because of minor faults may not prevent payment from becoming due. Acceptance with recorded reservations is often the safer way to document the phase and keep remediation moving.

Why acceptance need not waive defect claims

A customer may worry that its signature means “the system is complete and defect-free.” That is not what an acceptance report must say. The report can record the parties’ knowledge of the work’s condition at acceptance rather than express an intention to waive claims. Statutory defect liability under Article 638 § 1 in conjunction with Article 556 et seq. of the Civil Code remains relevant after acceptance, including for a defect the customer did not know about at the time.

Wording matters, however. A statement such as “the parties have no reservations whatsoever” may later be argued to have a broader effect than merely confirming that no comments were recorded that day. Article 65 § 2 of the Civil Code concerns the interpretation of declarations of intent.

Before signing:

1. Remove unqualified statements that neither party has any reservations.
2. Describe known non-blocking defects as immaterial under the relevant specified contract clause.
3. State that acceptance does not, by itself, confirm completeness or compliance with the pre-implementation analysis documentation and does not restrict the right to report defects.

A reservation of rights can help the customer sign without giving up defect claims—and help the supplier move to invoicing.

Six provisions for acceptance with reservations

1. Separate blocking from non-blocking comments

Give the report two categories of comments. Acceptance-blocking comments concern material defects and prevent acceptance. Non-blocking comments identify faults to be remedied after the phase is accepted.

Cross-reference the contract provision that defines a material defect. The word “material” alone leaves each party to apply its own threshold.

2. Calculate remedial periods from signing

Set remedial deadlines in business days from the date the report is signed, rather than using fixed calendar dates. A report may circulate for weeks. By the time both parties sign, a fixed deadline may already have passed, creating an immediate dispute about delay and penalties.

3. Specify what will be verified at later milestones

Some configured functions can only be fully checked during later activities, such as training, testing, data migration, or parallel operation. State that findings from those activities will follow the contract’s defect-reporting procedure and will not be treated as reservations against acceptance of the earlier phase.

This prevents every later defect report from reopening the question of whether the previous phase should have been accepted.

4. Record limitations of the standard product

A requested configuration may be unavailable because of a limitation in the manufacturer’s standard product, rather than the supplier’s work. If that is the agreed position, record all three points:

1. The limitation is not classified as a defect.
2. It is not a reservation blocking acceptance.
3. The customer has not abandoned the requirement; the parties will revisit it if the manufacturer makes the feature available.

5. Preserve rights expressly

State that accepting the phase does not confirm its completeness, correctness, or conformity with the pre-implementation analysis documentation, and does not restrict the right to report defects. The provision reinforces statutory defect rights, but its immediate value is practical: it makes a qualified sign-off possible.

6. List the accepted scope

Identify the functional areas actually covered by the phase—for example, finance, fixed assets, sales, KSeF (Poland’s National e-Invoicing System), document workflow, HR and payroll, time tracking, and analytics—and include integrations between the relevant modules.

Adapt the list to the project. A report that merely says “Phase 2 accepted” is weak evidence of whether a particular module or integration was included.

Contact us

The four-date test

An acceptance form may need four separate dates. Entering the date the document was prepared in every field can distort the schedule, remedial deadlines, and VAT analysis.

Apply the test before signing:

1. Record each date separately, using the underlying project evidence.
2. Check the submission date against the schedule and signed contract appendix.
3. Compare the acceptance and invoice dates, and examine any discrepancy for VAT risk.
4. Confirm that remedial periods run from the agreed trigger—preferably signing—rather than an already-expired fixed date.

The Minister of Finance’s General Interpretation No. DD3/033/101/CRS/13/RWPD-48186/RD states, as presented in the source, that a partial service is performed when the work is actually completed and submitted for acceptance, not merely when the report is signed (general interpretation). A signature documenting earlier work does not automatically move the VAT tax point. Where the contract makes phase acceptance conditional on a signed report, the document remains important evidence.

The nature of the supply also matters. The source distinguishes hardware as a supply of goods from implementation and configuration as services. Tax legislation does not provide self-contained definitions of every relevant concept, such as a license, a copyright work, or a computer program; classification depends on the interpretations of tax authorities and administrative courts. That classification affects VAT timing.

Do not use a construction-work form without adapting it

A counterparty may send an “acceptance report” with fields for a construction log, quantity measurements, or land-survey records. Those fields are a sign that a construction template has been copied into an IT project.

In V CSK 150/07, the Polish Supreme Court classified a contract covering software supply, installation, and launch as a mixed contract with predominant elements of a contract for specific work (umowa o dzieło) (Supreme Court judgment). The source identifies Article 643 of the Civil Code, concerning delivery and acceptance of specific work, rather than Article 647 on construction work, as the statutory acceptance reference for an implementation.

Construction case law may assist interpretation, but it does not automatically govern IT acceptance. The source identifies no established line of cases approving a general analogy between the two (Civil Code consolidated text).

When adapting a construction form:

1. Delete construction-specific fields that have no IT equivalent.
2. Limit the supporting-document checklist to documents the project actually uses, commonly the pre-implementation analysis and the contract with its appendices.
3. Keep a useful distinction between blocking and non-blocking comments.
4. Add a field for modules and integrations, so the accepted scope is described functionally.

Contractual penalties: the cost of an inaccurate date

Under Article 484 § 1 of the Civil Code, a contractual penalty is payable regardless of the amount of loss. A date entered in the report can therefore affect the penalty calculation even if the customer cannot show a corresponding financial loss.

The source gives these examples from proceedings before Poland’s National Appeals Chamber (Krajowa Izba Odwoławcza, or KIO), which hears public procurement disputes:

The source links to the KIO material concerning the 0.4% penalty and KIO 823/19. These are examples from individual proceedings, not market statistics or statutory rates.

The source identifies no statutory or official percentage cap for penalties in IT implementations. A more contained contractual approach is to calculate delay penalties on the remuneration for the affected phase, rather than the entire contract, and agree an aggregate cap. A court may reduce a grossly excessive penalty under Article 484 § 2 of the Civil Code; using the total contract value for a delay in one module increases the risk of that issue arising.

Define “material defect” in the implementation contract

Article 560 § 4 of the Civil Code says that a buyer cannot withdraw from a contract if a defect is immaterial, but it does not supply criteria tailored to an IT acceptance process (Civil Code text linked in the source). A contract’s acceptance-blocking “material defect” should therefore be defined on its own terms rather than left as an unexplained label.

One contractual approach described in the source is a P1–P4 priority structure:

This is contract practice, not a statutory classification. Connect each priority to response and resolution times in the service-level agreement (SLA). Otherwise, the parties may agree on severity but still dispute how quickly the supplier must act.

Also distinguish maintenance from functional development. If subscription fees do not clearly say whether they cover maintenance, new functionality, or both, the parties may dispute what was included in the accepted milestone.

Acceptance does not itself transfer copyright

Signing a phase acceptance report does not by itself transfer copyright if the contract does not expressly provide for transfer at that point and identify the relevant fields of exploitation—the specified ways the rights may be used. Article 41(2) of the Polish Copyright Act requires an agreement transferring rights to identify those fields expressly. Article 53 requires written form for a transfer agreement on pain of invalidity (Copyright Act consolidated text).

Address these matters separately in the contract:

1. When the phase is accepted.
2. When copyright transfers—whether at that acceptance, at final acceptance, or another agreed point.
3. What the transfer covers, such as source code, documentation, configurations, and graphic elements.
4. How open-source components are treated.
5. What rights apply to adaptations and other derivative works.

For a phased project, determine whether rights transfer with each partial acceptance report or only after final acceptance. Do not leave that question to be inferred from a signature.

An 18-point pre-signing checklist

Use this checklist on your own form and on any form supplied by the counterparty.

Additional constraints in Polish public procurement

If the customer is a public entity or a municipally owned company, consider whether Poland’s Public Procurement Law (Prawo zamówień publicznych, or PZP) applies. Article 433 restricts impermissible contractual provisions, while Article 436 addresses mandatory contract elements concerning penalties (Public Procurement Law text linked in the source).

The PZP does not prescribe one mandatory ERP acceptance-report template. Acceptance rules, defect categories, tests, and the consequences of refusing acceptance need to be clear in the procurement documents.

Sample agreements from the Polish Public Procurement Office’s miniPortal include penalties of 0.5% of remuneration for each day of delay and 20% for withdrawal for reasons attributable to the supplier. These are terms in particular templates, not generally applicable statutory limits (sample contract).

There may be limited room to amend a public procurement form. Even so, it is worth addressing the distinction between blocking and non-blocking comments and calculating remedial periods from signing.

Build a standard form and review incoming ones

Repeatedly editing a counterparty’s report from scratch takes time and increases the risk of missing an important point. For organizations running several implementations, a standard phase-acceptance form provides a consistent starting position. Incoming forms should still receive a legal review, with comments explaining proposed changes.

Treat sign-off as a formal project close-out review. Check that the report aligns with the contract’s scope, payment schedule, intellectual property provisions, SLAs, and exit arrangements. Train implementation teams and project management offices (PMOs) to record the condition of the work accurately—not to assume that signing certifies a defect-free system, or that every minor fault permits refusal.

Sawaryn & Partners advises on IT and AI implementations, including reviews of acceptance documents and material-defect provisions, standard forms for project portfolios, and milestone-acceptance disputes.

If a report is awaiting signature—or you want a consistent acceptance process across your projects—contact us.

Frequently asked questions

Does signing mean I lose the right to report defects?
No. Signing is not, by itself, a waiver of claims under the statutory defect-liability rules in Article 638 § 1 in conjunction with Article 556 et seq. of the Civil Code. Avoid broad “no reservations whatsoever” language, record known faults, and preserve the right to report defects.

Can a customer refuse a phase because several items are imperfect?
The distinction is between material defects that justify refusal and immaterial defects that should be recorded while the phase is accepted. An unjustified refusal creates risk for the customer: it may not prevent payment from becoming due or trigger penalties against the supplier. The source characterizes this as creditor delay, while citing Article 476 of the Civil Code.

Which date establishes service performance for VAT?
Do not assume it is the signing date. The Minister of Finance interpretation cited above points to actual completion and submission for acceptance of a partial service. The contract and report can be important evidence. Record completion, submission, acceptance, and signing separately, then check the invoice timing.

What if the counterparty says its form is “just a formality”?
Review it before signing. Check whether it was adapted from construction work, verify the four dates, identify the accepted modules and integrations, and ensure it distinguishes blocking from non-blocking comments. Use the 18-point checklist to structure proposed changes.

How long can claims relating to an accepted phase be pursued?
Under Article 646 of the Civil Code, claims under a contract for specific work become time-barred two years after the work is delivered. The source treats each partial report in a phased implementation as starting a separate period for claims concerning that phase. This makes accurate delivery and acceptance records important.

Should we use our own acceptance-report template?
Yes, particularly if you manage multiple projects. A standard form helps teams apply the same rules to scope, reservations, dates, remedial work, and signatures. Treat a counterparty’s form as a document to review and negotiate, not as something ready to sign unchanged.