---
title: "Einen Pass-Fail-Check vor der Submission bauen"
description: "Prüfen Sie jede Disqualifying Condition gegen Controlling Instructions, admissible Evidence und Final Package unabhängig vom Quality Review."
canonical: "https://zephior.com/de/insights/build-a-pass-fail-submission-check"
last-updated: 2026-09-02
---

# Einen Pass-Fail-Check vor der Submission bauen

> Prüfen Sie jede Disqualifying Condition gegen Controlling Instructions, admissible Evidence und Final Package unabhängig vom Quality Review.

Von [Tony Kim](https://zephior.com/de/authors/tony-kim). Veröffentlicht 2026-09-02; aktualisiert 2026-09-02. 7 Min. Lesezeit.

## Definition

Ein Pass-Fail Submission Check ist ein unabhängiger evidence-based Release Control für Conditions, die Evaluation oder Acceptance verhindern können. Er verfolgt jede Condition vom Controlling Source zu Bidder Action, admissible Proof und finalem Render oder Portal und erfasst Verified Result. Er ist getrennt von Persuasive Quality Review, Proofreading und Upload Operation. Ein starker Score kompensiert keinen Formal Failure.

## Problem

Final Reviews mischen Compliance, Writing und Visual Polish in ein Meeting. Reviewer diskutieren Executive Summary, während Declaration falsche Entity nutzt, Attachment unsigned bleibt oder Portal Answer vom PDF abweicht. Eine grüne Matrix kann Draft statt Released Files spiegeln. Familiarity erzeugt False Assurance: Producer markiert eigene Form complete. Bei Deadline wird „probably acceptable“ zu undokumentiertem Waiver ohne Authority.

## Perspektive

Bauen Sie Check aus Consequence statt Document Order. Identifizieren Sie Conditions, deren Failure exclude, reject, invalidate oder Evaluation verhindern kann. Bewahren Sie Exact Wording, Source Hierarchy und Clarifications. Definieren Sie Objective Pass Evidence vor Review. Ein unabhängiger Checker prüft Final Artifact und Portal State statt Draft oder Promise. Unknown und Conditional sind kein Pass. Exception braucht Buyer Rule und richtige Authority.

## Condition Set aus allen Controlling Surfaces bauen

Durchsuchen Sie Notice, Instructions, Participation Rules, Technical Requirements, Pricing Schedules, Declarations, Forms, Contract Schedules, Annexes, Clarifications, Addenda und Portal Fields. Erfassen Sie Mandatory Verbs, Shall Language, Exclusion Grounds, Thresholds, Formats, Attachments, Signatures, Limits und Deadline Actions. Eine Condition außerhalb des Main RFP kann trotzdem Acceptance steuern.

Erstellen Sie je Test eine atomare Condition. „Signed Technical und Financial Offers in separate Files“ enthält Content, Signature, Separation, Format und Upload Tests. Erfassen Sie Source, Version, Clause, Entity und Lot. Verlinken Sie Duplicates ohne Context zu löschen. Bei Conflict lösen Sie Controlling Instruction vor Pass Definition.

Klassifizieren Sie hard, scored und informational. Hard kann Evaluation oder Eligibility verhindern. Scored betrifft Points. Informational ist requested ohne gleiche Consequence. Halten Sie Interpretation sichtbar und clarifizieren Sie. World Bank und EBRD Packages zeigen, warum Instructions, Forms und Qualification gemeinsam geprüft werden.

**Condition Record**

| Feld | Inhalt | Zweck |
| --- | --- | --- |
| Source | Document, Version und Clause | Controlling Instruction |
| Condition | Ein Test | Kein Bundled Green |
| Applicability | Entity, Lot und Date | Right Scope |
| Pass Evidence | File, Field oder Signature | Objective Review |
| Roles | Producer, Checker und Blocker | Separate Assurance |

## Pass Proof früh definieren und Slow Cures testen

Definieren Sie Observable Pass State. „Form complete“ ist zu schwach. Sagen Sie, dass Mandatory Cells Approved Entity Data tragen, Calculations validieren, Signatures im Final PDF sichtbar sind und File im richtigen Portal Field liegt. Bei Certificate nennen Sie Issuer, Holder, Scope, Validity, Translation und Attachment Location.

Prechecken Sie Registrations, References, Insurance, Certifications, Powers, Consortium Commitments, Tax Declarations, Notarization und Original Signatures. Erfassen Sie pass, fail, conditional oder unknown. Conditional hat Event, Owner, Proof und Expiry. Unknown blockiert Green. Recheck at Release wegen Validity und File Change.

Trennen Sie Authenticity, Applicability und Final Use. Ein authentisches Certificate kann falschen Scope haben. Applicable Evidence kann im Package fehlen. Signed Form kann im Wrong Lot liegen. Unterschiedliche Failure Modes brauchen getrennte Checks, statt „wir haben es“ durch Assembly zu tragen.

- Observable Final Pass schreiben.
- External Evidence früh prüfen.
- Status explizit nutzen.
- Authenticity, Applicability und Use trennen.
- Nach Change reopen.

## Prüfen, was submitted wird statt Intended Work

Assignen Sie Checker, der Item nicht allein erzeugte. Er erhält Condition, Pass Proof und Final Candidate. Er öffnet Render, prüft Signature, Page Count, Fields, Attachment, Calculation und Location und erfasst Filename, Version, Page, Portal Field oder Validation. Er verlässt sich nicht auf Email.

Reconcile Manifest und Instructions in beide Richtungen. Jedes Required Item erscheint einmal korrekt; jedes Submitted File hat Purpose, Approved Version und Allowed Status. Prüfen Sie PDFs nach Conversion, Spreadsheets in Required Format und Portal Text gegen Narrative. Hidden Comments, Blank Pages und Broken Tables zählen.

Reopen Conditions nach Late Change. Corrected Entity Name kann Declarations, Pricing, Covers und Signatures betreffen. New Export kann Limits ändern. Replaced Sheet invalidiert Checked Total. Change Control nennt Retest. Frühere Initialen gelten nicht auf Changed Artifact.

**Final Review**

| Objekt | Direct Check | Unsafe Substitute |
| --- | --- | --- |
| PDF | Rendered Pages und Signature | Source looked correct |
| Spreadsheet | Formulas und Format | Totals in Email |
| Attachment | Identity, Scope und Manifest | Owner says exists |
| Portal | Final Saved Value | Draft List |
| Set | Required versus Included | Folder looks complete |

## Release blockieren, wenn Hard Condition nicht proven ist

Aggregieren Sie ohne Average. Jede Hard Condition zeigt Pass, Proof, Checker und Time. Ein Fail oder Unknown bleibt sichtbar. Citable Equivalent oder Exception braucht Buyer Rule und Internal Authority. Commercial Optimism ist keine Permission. Wenn nur Buyer waiven kann, beweist nur Authorized Buyer Communication dies.

Release Authority prüft Blockers, Changes, Buffer und Sign-offs. Release heißt Evidence stützt Hard Conditions für Exact Package, nicht High Score. Quality Review bleibt separat innerhalb Freeze Rules. Kann Condition vor Internal Start nicht passen, stop oder formal permitted route statt Unknown in Upload.

Retain Signed Record, Manifest, Approval, Receipt und permitted Portal Evidence. Nach Submission prüfen Sie Defects und Near Misses. Ergänzen Sie Source Coverage, Proof Definition und Freeze. Fügen Sie nicht generische Rows hinzu, sondern reparieren den Control, der Defect durchließ.

- Hard Results nie mitteln.
- Buyer Authority für Exception zitieren.
- Quality separat halten.
- Bei fehlendem Proof blockieren.
- Record behalten und Control verbessern.

## Nützliche Ergebnisse

- Jede Disqualifying Condition hat Controlled Record.
- Pass Criteria bestehen vor Review.
- Final File, Signature und Portal Field werden direkt geprüft.
- Producer und Checker bleiben getrennt.
- Unknowns und Exceptions bleiben sichtbar.
- Release Authority erhält Complete Pass Record.

## Ablauf

1. **Universe bilden.** Conditions aus Notice, Instructions, Forms, Annexes, Contract, Clarifications und Portal extrahieren.
2. **Pass Evidence definieren.** Action, Proof, Final Location, Producer und Checker je Condition festlegen.
3. **Früh prechecken.** Entity, Eligibility, Signatures, Certificates und External Evidence testen.
4. **Final Package prüfen.** Rendered Files, Calculations, Signatures, Manifest und Portal gegen Record prüfen.
5. **Release oder Block.** Nur mit Passed Hard Conditions oder explicitly authorized Treatment freigeben.

## Wichtige Entscheidungen

- Welche Conditions verhindern Evaluation?
- Welche Source controls?
- Welches Artifact beweist Pass?
- Wer produziert und wer checkt?
- Passt Evidence zu Entity, Lot und Date?
- Kann Defect vor Safe Window geheilt werden?
- Ist Equivalent oder Exception erlaubt?
- Wer darf blockieren oder releasen?

## Risiken

- Scored und Disqualifying werden verwechselt.
- Draft Check bleibt nach File Change grün.
- Certificate hat falsche Entity oder Scope.
- Signature geht beim Render verloren.
- Spreadsheet Validation schlägt fehl.
- Portal widerspricht Upload.
- Producer bestätigt sich selbst.
- Unknown wird unter Pressure zu Pass.

## Kennzahlen

- Hard Conditions mit Source und Proof
- Prechecks vor Final Day
- Final Artifacts unabhängig geprüft
- Scope Mismatches gefunden
- Conditions nach Change reopened
- Blockers vor Safe Upload eskaliert
- Releases mit Signed Record

## Häufige Fragen

### Reicht die Compliance Matrix?

Meist nicht. Sie mappt Requirements zu Draft Answers. Pass-Fail prüft Final Files, Signatures, Attachments und Portal gegen Release Proof.

### Darf Bid Manager selbst prüfen?

Producer Checks ja. High-consequence Release braucht Independent Checker, der Artifact nicht allein erstellt hat.

### Ist Unknown gleich Fail?

Nicht als Sachurteil, aber Unknown blockiert Pass. Lösen, Authority erhalten oder stoppen.

### Blockiert Quality Defect?

Nach separater Quality Decision. Dieser Check fokussiert Conditions, die Evaluation oder Acceptance verhindern.


## Primärquellen

- [World Bank Project Procurement Framework](https://www.worldbank.org/ext/en/what-we-do/project-procurement/framework), World Bank
- [EBRD Library of Procurement Forms](https://www.ebrd.com/home/work-with-us/project-procurement/library-of-forms-and-alternative-options.html), European Bank for Reconstruction and Development
- [Richtlinie 2014/24/EU](https://eur-lex.europa.eu/eli/dir/2014/24/oj/deu), EUR-Lex


## Weiterführende Artikel

- [Tender-Submission-Readiness-Review vor dem Release](https://zephior.com/de/solutions/tender-submission-readiness-review)
- [Welche Bedingungen können ein Angebot vor der Wertung stoppen?](https://zephior.com/de/insights/extract-pass-fail-gates-before-drafting)
- [Eine Tender-Compliance-Matrix als Freigabekontrolle aufbauen](https://zephior.com/de/insights/tender-compliance-matrix)
- [Wie schließt man offene Vergabefragen vor der finalen Freigabe?](https://zephior.com/de/insights/close-unresolved-tender-questions-before-release)