This is a ready-to-use log for tracking every executed batch record returned to manufacturing as unreviewable before the formal review began. Returning an incomplete record is normal and correct; not tracking that it happened is the gap. Without this log, a product or line that keeps generating unreviewable records looks like a series of unrelated one-off events instead of the pattern it actually is. Replace every <<FILL: ...>> placeholder. A filled specimen follows.
Column definitions
| Column | Format | Required | Notes |
|---|---|---|---|
| Return ID | Unique ID | Yes | Sequential, referenced from the batch record |
| Batch / lot number | ID | Yes | The record returned |
| Product / line | Text | Yes | Used for the trend view |
| Date returned | Date | Yes | Starts the correction clock, separate from the review clock |
| Criterion failed | One of the unreviewable criteria | Yes | See the batch record completeness and review readiness checklist for the full list |
| Detail | Text | Yes | The specific field, step, or entry |
| Returned by | Name / role | Yes | The screener or reviewer |
| Returned to | Name / role | Yes | Who owns the correction |
| Date resubmitted | Date | Yes | Ends the correction clock |
| Screened again on resubmission | Yes / No | Yes | Confirms the fix actually resolved the criterion, not just that something changed |
Repeat occurrence (same criterion, same product/line, within <<FILL: e.g. 90 days>>) | Yes / No | Yes | Drives the escalation trigger below |
Log (blank)
| Return ID | Batch / lot | Product / line | Date returned | Criterion failed | Detail | Returned by | Returned to | Date resubmitted | Screened again | Repeat |
|---|---|---|---|---|---|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
Control rules (state these in the governing SOP)
- Every return gets an entry, no exceptions. A record returned informally with no log entry defeats the purpose; the log has to be the complete population, not a sample of the ones someone remembered to write down.
- The correction clock is tracked separately from the review clock. Time spent making a record reviewable is not review time, and conflating the two hides both numbers; see the batch record review cycle time discussion for why this distinction matters.
- Resubmission is screened again, not assumed fixed. The reviewer confirms the specific criterion that failed is now met before proceeding, and notes whether any new issue was introduced by the correction itself.
- Two returns for the same criterion on the same product or line within
<<FILL: e.g. 90 days>>escalate to QA management as a process signal: the master record, the training, or the form design likely needs a fix, not just another individual correction. - Trend the log at least
<<FILL: e.g. monthly>>by product, line, and criterion, to surface a repeat source before it accumulates into a larger pattern or a finding.
Retention and review
Retain this log per <<FILL: retention period>>. Review it at the cadence in control rule 5 for repeat sources, and bring any escalated pattern to <<FILL: forum, e.g. the quality management review>>.
Filled specimen
The following shows a populated log covering three returns across two products, illustrating both a one-off correction and a repeat pattern that triggers escalation. Numbers and IDs are illustrative.
| Return ID | Batch / lot | Product / line | Date returned | Criterion failed | Detail | Returned by | Returned to | Date resubmitted | Screened again | Repeat |
|---|---|---|---|---|---|---|---|---|---|---|
| RFC-2026-041 | B-7742 | Tablet 25 mg, Line 2 | 2026-08-12 | Unexplained blank in a required field | Cleaning verification field on the equipment-use log left blank at step 4 | A. Patel (QA) | Line 2 supervisor | 2026-08-12 | Yes, Pass | No |
| RFC-2026-058 | B-7801 | Vial fill, Line 5 | 2026-08-20 | Missing second check on a critical step | No verifier signature on the final container-closure integrity check | R. Gomez (QA) | Line 5 supervisor | 2026-08-21 | Yes, Pass | No |
| RFC-2026-071 | B-7833 | Vial fill, Line 5 | 2026-09-01 | Missing second check on a critical step | Same field, container-closure integrity check, no verifier signature again | R. Gomez (QA) | Line 5 supervisor | 2026-09-02 | Yes, Pass | Yes, second occurrence within 90 days on the same field and line |
The third row triggered escalation under control rule 4: the same field on the same line was missed twice within three weeks. The trend review found the master record’s verification box for that step was positioned below a page break where it was easy to miss, a form-design gap, not two unrelated operator errors, and the master record was revised under change control to move the signature block above the break.
Common inspection findings this log prevents
- Batch records returned informally with no record of the return, so the volume and pattern of unreviewable records is invisible.
- A record returned and resubmitted with no confirmation the specific defect was actually corrected.
- Review time and correction time reported as one undifferentiated number, hiding whether the review itself is slow or the records arriving for review are simply not ready.
- A repeat source, the same field, the same line, the same criterion, treated as a series of unrelated one-off corrections instead of the process signal it actually is.
How to adapt this log
- Set your escalation window and cadence in control rules 4 and 5 to match your batch volume and risk profile.
- Link the criterion-failed column values directly to your unreviewable-criteria list so the two stay in sync when either changes.
- If your system logs returns electronically, this log is the human-readable trend view; enforce the “screened again on resubmission” step in the system workflow, not in memory.
- Feed the repeat-occurrence trend into your batch record review metrics program alongside cycle time and finding rate.