Document Review Codes Explained: A, B, C, D — and the Response Codes That Go With Them
A review code is a contractual statement about a document, not a formality. Photo: Anna Tarazevich via Pexels.
Three Code Systems, One Process
Document review on AEC and EPC projects runs on a handful of small code systems that everyone uses and almost nobody defines. Two of them do the day-to-day work:
- Review codes (also called return codes or status codes) — the overall verdict on a submitted document: A, B, C, D or Code 1–4.
- Response codes — the author's answer to each individual comment: Accepted, Accepted with Comment, Rejected, Clarification Needed.
A third — revision codes — identifies which version of the document is being discussed, and is covered further down along with a side-by-side comparison of all three.
Confusing them — or using them loosely — is a quiet source of schedule slippage and contractual risk. Here is how each set works and the rules that keep them meaningful.
Review Codes: The Document-Level Verdict
| Code | Common Label | Meaning | Can Work Proceed? |
|---|---|---|---|
| A / Code 1 | Approved | No comments; document accepted as submitted | Yes |
| B / Code 2 | Approved with comments | Minor comments; incorporate and resubmit for record | Yes, incorporating comments |
| C / Code 3 | Revise and resubmit | Significant comments; document not accepted | No |
| D / Code 4 | Rejected | Fundamental non-compliance or wrong basis | No |
Exact labels vary by contract (some projects use "Reviewed — no exceptions taken" style language), but the structure is near-universal. Three rules keep review codes honest:
- The code must match the comments. A "B" with an unresolved technical comment is a contradiction that will be read against you in a dispute. If a comment blocks construction, the code is C.
- The code applies to a specific revision. "Approved" means this revision — which is why revision traceability in your comment record matters.
- Code inflation is a schedule debt. Teams under pressure hand out B codes to keep work moving, then discover at close-out that dozens of "minor" comments were never incorporated.
Response Codes: The Comment-Level Answer
Each comment in a comment resolution sheet gets its own response code from the document author:
| Response Code | Meaning | What Happens Next |
|---|---|---|
| Accepted | Author agrees; change will be made | Reviewer verifies the change in the next revision, then closes |
| Accepted with Comment | Agrees in substance, with a qualification | Reviewer checks the qualification is acceptable |
| Rejected | Author disagrees, with justification | Reviewer accepts the justification or escalates to discussion |
| Clarification Needed | Comment is ambiguous or lacks basis | Reviewer restates the comment as a verifiable requirement |
The critical discipline: a response is not a resolution. "Accepted" moves a comment to Answered, not Closed. Closure happens only when the reviewer verifies the change in the revised document. Teams that let authors close their own comments have a comment log that proves nothing — the permission model we describe in Role-Based Permissions in AEC Collaboration.
Rejected Comments Are Not Failures
A well-justified rejection is a healthy outcome — it means the requirement was tested and the document survived. What is not healthy is a rejection that ends the conversation: every rejected comment needs either the reviewer's explicit acceptance of the justification or an escalation to a named decision-maker. Rejections that just sit there are open disputes wearing a closed costume, and they resurface during commissioning or claims.
Revision Codes: Which Version Are We Talking About?
There is a third code system that gets confused with the first two constantly, and it answers a different question again. A revision code identifies which version of a document you are holding — it says nothing about whether that version was approved.
Two conventions dominate:
| Convention | Sequence | Typical use |
|---|---|---|
| Alphabetic (preliminary) → numeric (issued) | Rev A, B, C … then Rev 0, 1, 2 … | Letters for pre-approval drafts; numbers from the first issued-for-construction version onward |
| Prefixed (ISO 19650 style) | P01, P02 … then C01, C02 … | P = preliminary/work in progress, C = contractual/issued |
The rules that keep revision codes usable are unglamorous and routinely broken:
- A revision code is never reused or edited. Re-issuing "Rev B" with different content destroys the ability to say which version a comment was raised against.
- Every issue gets a new revision, including minor ones. "Same rev, small fix" is how two different PDFs end up with the same number in two inboxes.
- The revision is part of the comment record, not just the file name. A comment belongs to a document at a revision; without that pairing you cannot show what was resolved when.
Three Code Systems, Side by Side
Most of the confusion in document control comes from these three answering three different questions:
| System | Question it answers | Example values | Applies to |
|---|---|---|---|
| Revision code | Which version is this? | Rev A / Rev 0 / P01 / C01 | The document |
| Review code | Was this version accepted? | A, B, C, D or Code 1–4 | The document, at one revision |
| Response code | What did the author do about this comment? | Accepted, Accepted with Comment, Rejected, Clarification Needed | One comment |
A fourth system sits alongside these on ISO 19650 projects: suitability (status) codes — S0–S5, A and B — which state what a version may be used for, not whether it was approved. Those are covered separately in ISO 19650 Status Codes Explained.
The practical test for whether your project is using them correctly: given any document, you should be able to state its current revision, the review code that revision received, and the response code and status of every comment raised against it. If any of those three requires asking someone, the record is not defensible.
Tracking Codes Without Losing Your Mind
In a spreadsheet, code discipline depends entirely on people: nothing stops an author from typing "Closed", nothing flags a B-coded document with open comments, and nothing carries an unresolved rejection into the next revision. This is exactly the class of problem we built Contrat.io to remove — response codes and statuses are enforced by role, revisions inherit open comments automatically, and the code history of every document is a click away. Try it free for 30 days, no credit card required. For the fuller picture of a compliant review record, see The Ultimate Guide to EPC Document Control.
Frequently Asked Questions
What do document review codes A, B, C, and D mean?
A (Approved) has no comments; B (Approved with comments) lets work proceed while incorporating minor comments; C (Revise and resubmit) means significant comments and no approval; D (Rejected) means fundamental non-compliance.
What is the difference between review codes and response codes?
Review codes are the document-level verdict (A/B/C/D). Response codes are the author’s answer to each individual comment: Accepted, Accepted with Comment, Rejected, or Clarification Needed.
Does a Code C or D mean the submission failed?
Not as a failure of the team. C and D mean work cannot proceed on that revision yet — the document needs revision and resubmission before it can be approved.
Is a rejected comment a bad thing?
No. A well-justified rejection means the requirement was tested and the document survived. What matters is that every rejection is either accepted by the reviewer or escalated — never left open.
What is a revision code?
A revision code identifies which version of a document you are looking at — Rev A, B, C then Rev 0, 1, 2, or P01/C01 under ISO 19650-style numbering. It says nothing about whether that version was approved; that is the review code.
What is the difference between a revision code and a review code?
The revision code answers "which version is this?" and belongs to the document. The review code answers "was this version accepted?" and applies to one specific revision. A document can carry many revisions, each with its own review code.
What is the difference between review codes and ISO 19650 status codes?
A review code (A/B/C/D) is a verdict on whether a submitted revision is accepted. An ISO 19650 suitability or status code (S0–S5, A, B) states what the version may be used for. They travel together but answer different questions.