{"id":3016,"date":"2026-10-21T15:42:01","date_gmt":"2026-10-21T15:42:01","guid":{"rendered":"https:\/\/sawaryn.com\/us\/?p=3016"},"modified":"2026-10-21T15:42:24","modified_gmt":"2026-10-21T15:42:24","slug":"poland-it-phase-acceptance-report","status":"publish","type":"post","link":"https:\/\/sawaryn.com\/us\/poland-it-phase-acceptance-report\/","title":{"rendered":"Accepting an IT Implementation Phase in Poland: What the Sign-Off Report Really Does"},"content":{"rendered":"

Accepting an IT Implementation Phase in Poland: What the Sign-Off Report Really Does<\/h1>\n

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<\/a> arises, when defect-liability periods begin, whether delay penalties accrue, what work has been accepted, and when the limitation period for claims starts.<\/p>\n

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.<\/p>\n

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

Polish terms that matter at acceptance<\/h2>\n

The distinctions below should also be reflected in the contract. In particular, the contract should define which defects block acceptance.<\/p>\n\n\n\n\n\n\n\n\n\n
Term<\/th>\nMeaning<\/th>\nWhy it matters<\/th>\n<\/tr>\n<\/thead>\n
Material defect<\/strong><\/td>\nA defect that prevents the system from being used for its intended purpose. There is no statutory definition tailored to this acceptance distinction, so the contract should specify the criteria.<\/td>\nA material defect can justify refusal of acceptance; a minor defect generally should not.<\/td>\n<\/tr>\n
Immaterial defect<\/strong><\/td>\nA fault that does not prevent the system from operating.<\/td>\nThe customer can record it, accept the phase with reservations, and request a remedy without necessarily blocking invoicing.<\/td>\n<\/tr>\n
Statutory defect liability (r\u0119kojmia<\/em>)<\/strong><\/td>\nThe contractor\u2019s liability for defects in work under Article 638 \u00a7 1 in conjunction with Article 556 et seq. of the Polish Civil Code. It is distinct from any contractual guarantee.<\/td>\nSigning an acceptance report does not, by itself, exhaust the customer\u2019s defect rights.<\/td>\n<\/tr>\n
Contractual penalty (kara umowna<\/em>)<\/strong><\/td>\nAn agreed amount payable for breach of a non-monetary obligation under Article 483 \u00a7 1 of the Civil Code, without a need to prove the amount of loss.<\/td>\nThe dates recorded in the report can affect the number of days for which a penalty is calculated.<\/td>\n<\/tr>\n
Acceptance-blocking and non-blocking comments<\/strong><\/td>\nContractual categories of reservations. Blocking comments prevent acceptance; non-blocking comments allow acceptance with a list of faults to remedy.<\/td>\nWithout this distinction, the parties may dispute whether any recorded comment prevents acceptance.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Six consequences of signing an acceptance report<\/h2>\n

An acceptance report is more than a receipt for completed work. Read it alongside the contract, payment schedule, defect provisions, and invoicing arrangements.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Issue<\/th>\nPolish-law reference<\/th>\nPractical effect<\/th>\n<\/tr>\n<\/thead>\n
Payment for a milestone<\/strong><\/td>\nArticle 642 \u00a7\u00a7 1\u20132 of the Civil Code<\/td>\nAcceptance can establish the supplier\u2019s entitlement to invoice for the phase.<\/td>\n<\/tr>\n
VAT timing<\/strong><\/td>\nArticle 19a(2) of the Polish VAT Act<\/td>\nThe tax obligation for a separately payable part of a service arises when that part is performed. Signing and performance may occur on different dates.<\/td>\n<\/tr>\n
Statutory defect liability and contractual guarantee periods<\/strong><\/td>\nArticle 638 \u00a7 1 in conjunction with Article 556 of the Civil Code<\/td>\nThe acceptance date is relevant to the periods during which defects can be reported.<\/td>\n<\/tr>\n
Delay and contractual penalties<\/strong><\/td>\nArticles 476 and 483\u2013484 of the Civil Code<\/td>\nThe report\u2019s dates can affect whether the supplier is treated as late and how penalties are calculated.<\/td>\n<\/tr>\n
Scope treated as completed<\/strong><\/td>\nThe contract and the report<\/td>\nAn itemized list of modules and integrations provides evidence of what was accepted. \u201cPhase 2 accepted\u201d leaves more room for dispute.<\/td>\n<\/tr>\n
Limitation period for claims<\/strong><\/td>\nArticle 646 of the Civil Code<\/td>\nClaims under a contract for specific work become time-barred two years after delivery of the work. The report\u2019s dates can be important evidence of when that occurred.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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<\/strong> while linking to a document labeled IV CSK 610\/13<\/strong>; 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>). A Court of Appeal judgment, I AGa 216\/22<\/strong>, states that where defects are immaterial, the customer should accept the work and use its statutory defect remedies (Court of Appeal judgment<\/a>).<\/p>\n

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<\/strong> is often the safer way to document the phase and keep remediation moving.<\/p>\n

Why acceptance need not waive defect claims<\/h2>\n

A customer may worry that its signature means \u201cthe system is complete and defect-free.\u201d That is not what an acceptance report must say. The report can record the parties\u2019 knowledge of the work\u2019s condition at acceptance rather than express an intention to waive claims. Statutory defect liability under Article 638 \u00a7 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.<\/p>\n

Wording matters, however. A statement such as \u201cthe parties have no reservations whatsoever\u201d<\/strong> may later be argued to have a broader effect than merely confirming that no comments were recorded that day. Article 65 \u00a7 2 of the Civil Code concerns the interpretation of declarations of intent.<\/p>\n

Before signing:<\/p>\n

    \n
  1. Remove unqualified statements that neither party has any reservations.<\/li>\n
  2. Describe known non-blocking defects as immaterial under the relevant specified contract clause<\/strong>.<\/li>\n
  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.<\/li>\n<\/ol>\n

    A reservation of rights can help the customer sign without giving up defect claims\u2014and help the supplier move to invoicing.<\/p>\n

    Six provisions for acceptance with reservations<\/h2>\n

    1. Separate blocking from non-blocking comments<\/h3>\n

    Give the report two categories of comments. Acceptance-blocking comments<\/strong> concern material defects and prevent acceptance. Non-blocking comments<\/strong> identify faults to be remedied after the phase is accepted.<\/p>\n

    Cross-reference the contract provision that defines a material defect. The word \u201cmaterial\u201d alone leaves each party to apply its own threshold.<\/p>\n

    2. Calculate remedial periods from signing<\/h3>\n

    Set remedial deadlines in business days from the date the report is signed<\/strong>, 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.<\/p>\n

    3. Specify what will be verified at later milestones<\/h3>\n

    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\u2019s defect-reporting procedure and will not be treated as reservations against acceptance of the earlier phase<\/strong>.<\/p>\n

    This prevents every later defect report from reopening the question of whether the previous phase should have been accepted.<\/p>\n

    4. Record limitations of the standard product<\/h3>\n

    A requested configuration may be unavailable because of a limitation in the manufacturer\u2019s standard product, rather than the supplier\u2019s work. If that is the agreed position, record all three points:<\/p>\n

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

      5. Preserve rights expressly<\/h3>\n

      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.<\/p>\n

      6. List the accepted scope<\/h3>\n

      Identify the functional areas actually covered by the phase\u2014for example, finance, fixed assets, sales, KSeF<\/strong> (Poland\u2019s National e-Invoicing System), document workflow, HR and payroll, time tracking, and analytics\u2014and include integrations between the relevant modules<\/strong>.<\/p>\n

      Adapt the list to the project. A report that merely says \u201cPhase 2 accepted\u201d is weak evidence of whether a particular module or integration was included.<\/p>\n

      Contact us<\/a><\/p>\n

      The four-date test<\/h2>\n

      An acceptance form may need four separate dates<\/strong>. Entering the date the document was prepared in every field can distort the schedule, remedial deadlines, and VAT analysis.<\/p>\n\n\n\n\n\n\n\n\n
      Date<\/th>\nWhat it records<\/th>\nWhy it matters<\/th>\nCommon mistake<\/th>\n<\/tr>\n<\/thead>\n
      Work completion date<\/strong><\/td>\nWhen the supplier actually finished the phase work.<\/td>\nHelps establish whether the delivery schedule was met.<\/td>\nUsing the date the report was drafted.<\/td>\n<\/tr>\n
      Date submitted for acceptance<\/strong><\/td>\nWhen the work was delivered for acceptance within the meaning of Article 643 of the Civil Code.<\/td>\nStarts the customer\u2019s contractual period for acceptance activities.<\/td>\nTreating it as the report-drafting date.<\/td>\n<\/tr>\n
      Acceptance date<\/strong><\/td>\nWhen the customer confirms acceptance of the phase.<\/td>\nRelevant to statutory defect liability and contractual guarantee periods; commonly treated as significant for VAT timing.<\/td>\nAssuming it must be the date of the signatures.<\/td>\n<\/tr>\n
      Signing date<\/strong><\/td>\nWhen both parties sign the report.<\/td>\nA recommended starting point for remedial periods.<\/td>\nTreating late signatures as proof that acceptance itself occurred late.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      Apply the test before signing:<\/p>\n

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

        The Minister of Finance\u2019s General Interpretation No. DD3\/033\/101\/CRS\/13\/RWPD-48186\/RD<\/strong> 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>). 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.<\/p>\n

        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.<\/p>\n

        Do not use a construction-work form without adapting it<\/h2>\n

        A counterparty may send an \u201cacceptance report\u201d 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.<\/p>\n

        In V CSK 150\/07<\/strong>, 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<\/strong> (umowa o dzie\u0142o<\/em>) (Supreme Court judgment<\/a>). 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.<\/p>\n

        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<\/a>).<\/p>\n

        When adapting a construction form:<\/p>\n

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

          Contractual penalties: the cost of an inaccurate date<\/h2>\n

          Under Article 484 \u00a7 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.<\/p>\n

          The source gives these examples from proceedings before Poland\u2019s National Appeals Chamber (Krajowa Izba Odwo\u0142awcza<\/em>, or KIO<\/strong>), which hears public procurement disputes:<\/p>\n\n\n\n\n\n\n\n
          Proceeding<\/th>\nRate described<\/th>\nPoint illustrated<\/th>\n<\/tr>\n<\/thead>\n
          KIO 2128\/15<\/strong><\/td>\n0.02% of the maximum contract value per business day<\/td>\nA low daily percentage can still be significant when applied to the whole contract.<\/td>\n<\/tr>\n
          KIO example identified in the source\u2019s research<\/strong><\/td>\n0.4% of the net remuneration for the phase for each day of delay<\/td>\nA phase-based calculation is a narrower structure.<\/td>\n<\/tr>\n
          KIO 823\/19<\/strong><\/td>\nPLN 70,000 per day of delay<\/td>\nThe source does not provide the contract value, so the rate cannot be converted into a percentage.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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

          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 \u00a7 2 of the Civil Code; using the total contract value for a delay in one module increases the risk of that issue arising.<\/p>\n

          Define \u201cmaterial defect\u201d in the implementation contract<\/h2>\n

          Article 560 \u00a7 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>). A contract\u2019s acceptance-blocking \u201cmaterial defect\u201d should therefore be defined on its own terms rather than left as an unexplained label.<\/p>\n

          One contractual approach described in the source is a P1\u2013P4 priority structure<\/strong>:<\/p>\n\n\n\n\n\n\n\n\n
          Priority<\/th>\nDescription<\/th>\nProposed acceptance treatment<\/th>\n<\/tr>\n<\/thead>\n
          P1 \u2014 Blocking<\/strong><\/td>\nThe system or module will not start, data is corrupted, and there is no workaround.<\/td>\nBlocking comment; acceptance does not proceed.<\/td>\n<\/tr>\n
          P2 \u2014 Major<\/strong><\/td>\nA business function does not work correctly, but a workaround exists.<\/td>\nNon-blocking comment; accept with a reservation and remedial deadline.<\/td>\n<\/tr>\n
          P3 \u2014 Standard<\/strong><\/td>\nA fault affects ease of use but not the result.<\/td>\nNon-blocking comment; address through maintenance.<\/td>\n<\/tr>\n
          P4 \u2014 Cosmetic<\/strong><\/td>\nA visual defect or interface typo.<\/td>\nNon-blocking comment; address in the next update.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

          This is contract practice, not a statutory classification<\/strong>. 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.<\/p>\n

          Also distinguish maintenance<\/strong> from functional development<\/strong>. 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.<\/p>\n

          Acceptance does not itself transfer copyright<\/h2>\n

          Signing a phase acceptance report does not by itself transfer copyright<\/strong> if the contract does not expressly provide for transfer at that point and identify the relevant fields of exploitation<\/em>\u2014the 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<\/a>).<\/p>\n

          Address these matters separately in the contract:<\/p>\n

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

            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.<\/p>\n

            An 18-point pre-signing checklist<\/h2>\n

            Use this checklist on your own form and on any form supplied by the counterparty.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
            No.<\/th>\nCheckpoint<\/th>\nQuestion to ask<\/th>\n<\/tr>\n<\/thead>\n
            1<\/td>\nTemplate origin<\/td>\nWas this copied from a construction project, and does it need trimming?<\/td>\n<\/tr>\n
            2<\/td>\nScope<\/td>\nDoes it list accepted modules rather than just a phase number?<\/td>\n<\/tr>\n
            3<\/td>\nIntegrations<\/td>\nDoes it expressly include integrations between relevant modules?<\/td>\n<\/tr>\n
            4<\/td>\nComment categories<\/td>\nDoes it distinguish blocking from non-blocking comments and refer to the contract?<\/td>\n<\/tr>\n
            5<\/td>\nMaterial defect<\/td>\nDoes the contract define the threshold, for example through an agreed P1\u2013P4 classification?<\/td>\n<\/tr>\n
            6<\/td>\nRemedial period<\/td>\nDoes it run from signing rather than an inflexible calendar date?<\/td>\n<\/tr>\n
            7<\/td>\nLater defect reports<\/td>\nWill findings from later phases follow the contract\u2019s defect-reporting procedure?<\/td>\n<\/tr>\n
            8<\/td>\nPreservation of rights<\/td>\nDoes acceptance avoid confirming completeness or restricting later defect reports?<\/td>\n<\/tr>\n
            9<\/td>\nFour dates<\/td>\nAre completion, submission, acceptance, and signing recorded separately?<\/td>\n<\/tr>\n
            10<\/td>\nSubmission and schedule<\/td>\nIs the submission date consistent with the actual work and signed schedule?<\/td>\n<\/tr>\n
            11<\/td>\nAcceptance and invoice<\/td>\nHas any difference between these dates been checked for VAT risk?<\/td>\n<\/tr>\n
            12<\/td>\nInvoicing basis<\/td>\nDoes the report identify the contract provision allowing the milestone invoice?<\/td>\n<\/tr>\n
            13<\/td>\nAmount<\/td>\nDoes the report match the payment schedule?<\/td>\n<\/tr>\n
            14<\/td>\nSupporting documents<\/td>\nDoes the checklist contain only documents relevant to this IT project?<\/td>\n<\/tr>\n
            15<\/td>\nSignatories<\/td>\nWill authorized people sign for both parties?<\/td>\n<\/tr>\n
            16<\/td>\nStandard-product limitations<\/td>\nAre they described, where appropriate, as not a defect, not an acceptance reservation, and not an abandoned requirement?<\/td>\n<\/tr>\n
            17<\/td>\nCopyright<\/td>\nDoes the contract address transfer timing separately from acceptance?<\/td>\n<\/tr>\n
            18<\/td>\nLicense subscription<\/td>\nDoes the recorded subscription period reflect the purchase date from the manufacturer rather than being assumed to start on the invoice date?<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

            Additional constraints in Polish public procurement<\/h2>\n

            If the customer is a public entity or a municipally owned company, consider whether Poland\u2019s Public Procurement Law<\/strong> (Prawo zam\u00f3wie\u0144 publicznych<\/em>, or PZP<\/strong>) applies. Article 433 restricts impermissible contractual provisions, while Article 436 addresses mandatory contract elements concerning penalties (Public Procurement Law text linked in the source<\/a>).<\/p>\n

            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.<\/p>\n

            Sample agreements from the Polish Public Procurement Office\u2019s miniPortal include penalties of 0.5% of remuneration for each day of delay<\/strong> and 20% for withdrawal for reasons attributable to the supplier<\/strong>. These are terms in particular templates, not generally applicable statutory limits<\/strong> (sample contract<\/a>).<\/p>\n

            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.<\/p>\n

            Build a standard form and review incoming ones<\/h2>\n

            Repeatedly editing a counterparty\u2019s 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.<\/p>\n

            Treat sign-off as a formal project close-out review. Check that the report aligns with the contract\u2019s 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\u2014not to assume that signing certifies a defect-free system, or that every minor fault permits refusal.<\/p>\n

            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.<\/p>\n\n\n\n\n\n\n\n
            Engagement<\/th>\nScope<\/th>\nSuitable for<\/th>\n<\/tr>\n<\/thead>\n
            One-off review<\/strong><\/td>\nComments and recommendations on a report before signing.<\/td>\nA supplier or customer facing one immediate sign-off.<\/td>\n<\/tr>\n
            Standard documentation<\/strong><\/td>\nA tailored report form and team checklist.<\/td>\nAn implementation business managing several projects.<\/td>\n<\/tr>\n
            Process audit<\/strong><\/td>\nReview of consistency across the contract, schedule, report, and invoice.<\/td>\nAn IT integrator or customer preparing for a major ERP implementation.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

            If a report is awaiting signature\u2014or you want a consistent acceptance process across your projects\u2014contact us<\/a>.<\/p>\n

            Frequently asked questions<\/h2>\n

            Does signing mean I lose the right to report defects?<\/strong>
            \nNo. Signing is not, by itself, a waiver of claims under the statutory defect-liability rules in Article 638 \u00a7 1 in conjunction with Article 556 et seq. of the Civil Code. Avoid broad \u201cno reservations whatsoever\u201d language, record known faults, and preserve the right to report defects.<\/p>\n

            Can a customer refuse a phase because several items are imperfect?<\/strong>
            \nThe 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.<\/p>\n

            Which date establishes service performance for VAT?<\/strong>
            \nDo 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.<\/p>\n

            What if the counterparty says its form is \u201cjust a formality\u201d?<\/strong>
            \nReview 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.<\/p>\n

            How long can claims relating to an accepted phase be pursued?<\/strong>
            \nUnder 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.<\/p>\n

            Should we use our own acceptance-report template?<\/strong>
            \nYes, 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\u2019s form as a document to review and negotiate, not as something ready to sign unchanged.<\/p>\n","protected":false},"excerpt":{"rendered":"

            For projects under Polish law, learn how to sign off an IT phase with reservations, preserve defect claims, and check dates that affect invoicing and VAT.<\/p>\n","protected":false},"author":14,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":"","sip_alt_url":"https:\/\/sawaryn.com\/publikacje\/protokol-odbioru-wdrozenia-it\/","sip_en_pl_url":"https:\/\/sawaryn.com\/en\/publikacje\/it-implementation-phase-acceptance-report-defect-claims\/","sip_pair_uuid":"2fc6ca07-e0b7-4009-bde9-5eedc1392db0","sip_pair_state":"verified"},"categories":[1],"tags":[1240,1241,1245,746,831],"specialization":[1129],"practice_area":[],"class_list":["post-3016","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-contractual-penalties","tag-copyright-law","tag-it-implementation-agreement","tag-sla","tag-taxes","specialization-it-ai-ip"],"acf":[],"_links":{"self":[{"href":"https:\/\/sawaryn.com\/us\/wp-json\/wp\/v2\/posts\/3016","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sawaryn.com\/us\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sawaryn.com\/us\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sawaryn.com\/us\/wp-json\/wp\/v2\/users\/14"}],"replies":[{"embeddable":true,"href":"https:\/\/sawaryn.com\/us\/wp-json\/wp\/v2\/comments?post=3016"}],"version-history":[{"count":1,"href":"https:\/\/sawaryn.com\/us\/wp-json\/wp\/v2\/posts\/3016\/revisions"}],"predecessor-version":[{"id":3017,"href":"https:\/\/sawaryn.com\/us\/wp-json\/wp\/v2\/posts\/3016\/revisions\/3017"}],"wp:attachment":[{"href":"https:\/\/sawaryn.com\/us\/wp-json\/wp\/v2\/media?parent=3016"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sawaryn.com\/us\/wp-json\/wp\/v2\/categories?post=3016"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sawaryn.com\/us\/wp-json\/wp\/v2\/tags?post=3016"},{"taxonomy":"specialization","embeddable":true,"href":"https:\/\/sawaryn.com\/us\/wp-json\/wp\/v2\/specialization?post=3016"},{"taxonomy":"practice_area","embeddable":true,"href":"https:\/\/sawaryn.com\/us\/wp-json\/wp\/v2\/practice_area?post=3016"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}