Mandatory comments are workflow rules that require a user to enter an explanation before completing a defined action, such as rejecting an invoice, overriding a validation rule, or approving an exception. Mandatory comment logic goes one step further: the platform checks that the comment is substantive, pairs it with a reason code, and stores it in a record nobody can quietly edit later.
A required text box on its own is weak governance. Users learn within a week that “ok” or “N/A” satisfies it, and the audit trail fills with entries that explain nothing. This guide covers which actions need a comment, how to keep the text meaningful, and how to test and review the rule once it is live.
What is mandatory comment logic on a legal platform?
Mandatory comment logic on a legal platform is a configured rule that blocks a defined action until the user supplies a reason code and a substantive explanation. It turns a decision that would otherwise leave no trace into an attributable, time-stamped record.
The difference between a required field and real comment logic sits in the validation. A required field accepts any characters. Comment logic checks the content, applies different standards to different roles, and keeps the original text even if the record changes later.
On ELM, eBilling, and CLM builds, comment logic usually touches four to eight actions. Getting those few right matters more than requiring comments everywhere, because every extra prompt adds friction and pushes users toward filler.
Which actions should require mandatory comments?
Mandatory comments should apply to actions that reject, override, or change a controlled record, because those are the decisions someone will later ask about. Five action types cover most legal platforms:
- Invoice rejection and adjustment. Any rejected invoice or reduced line item, where the law firm needs to know exactly what to fix.
- Validation overrides. A user bypassing a billing rule, budget limit, or required-field check.
- Exception approvals. Off-panel firms, rate exceptions, and budget increases approved outside the standard route.
- Status changes. Closing, reopening, or putting a matter or contract on hold.
- Record changes and deletions. Vendor category changes, deleted documents, and edits to approved budgets.
Keep routine actions free of prompts. Saving a draft, adding a note, or assigning a task should never ask for a justification.
Why should reason codes be paired with comments?
Reason codes should be paired with comments because the code makes each decision reportable and the comment makes it understandable. A code alone cannot explain the specific problem, and free text alone cannot be counted.
For invoice rejection, a short code list works well: duplicate invoice, wrong matter, rate not approved, unsupported expense, and other. Keep the list to five to eight values, and require a longer comment when the user picks “other”. Codes then feed a monthly report showing which firms trigger which problems, while the comment tells the firm what to correct.
Codes also anchor each rejection to a published rule, which matters more as volumes rise: billing data from about 400 law firms shows invoice rejection rates climbed from 11 to 18 percent in 2025. Billing guidelines only reject noncompliant invoice lines once they exist as configured rules, and the reason code list should mirror the sections of those guidelines.
How do you stop filler text in required comments?
You stop filler text in required comments by validating the content before the action completes, using a short set of checks that reject obvious placeholders. The checks should be strict enough to block “N/A” and loose enough that a genuine one-line explanation passes.
Four checks catch most filler:
- Placeholder blocklist. Reject entries such as “N/A”, “none”, “ok”, “see above”, and a single period.
- Repeated characters. Reject strings like “xxxx” or “…..” that only exist to satisfy the field.
- Minimum length, used sparingly. A floor of 15 to 25 characters on high-risk actions works; higher floors invite padding. Test it at the limit with boundary value analysis.
- Template prompts. Placeholder text such as “Describe what the firm must correct” guides the user toward a useful answer.
Show the reason for a blocked comment in plain language. “Please describe the specific issue so the firm can correct it” gets a better second attempt than a generic validation error.
Should mandatory comment rules vary by user role?
Mandatory comment rules should vary by user role, with stricter requirements for users who hold more power over the record. An approver overriding a control needs a fuller explanation than a reviewer flagging a line item.
A three-level model fits most departments:
- Reviewers. A reason code and a short comment on rejections and adjustments.
- Approvers. A reason code, a comment meeting the minimum length, and a second approval for exceptions above a set value.
- Administrators. A comment on every override or configuration change, routed to a weekly review report.
Role-based rules need role-based testing. Role-based security testing confirms each user sees and does only what their role allows, and the same test pass should confirm each role hits the right comment requirement.
What should the audit trail capture with each comment?
The audit trail should capture who acted, when, on which record, what changed, and the comment and reason code they entered. Those five elements make each comment usable as internal-control evidence.
Capture these fields on every comment event:
- User and role. The named user and the role they held at the time of the action.
- Timestamp and action. The exact time and the action taken, such as reject, override, or approve.
- Record and values. The record ID and the field values before and after the change.
- Comment and code. The reason code and the full comment text, locked once saved.
Comments should be immutable. If your process allows a correction, store it as a new version and keep the original visible in the history. Required comments support internal controls, and a SOX audit trail is expected to show the first version as well as the last.
How should invoice rejection comments be written?
Invoice rejection comments should be written with a reason code and a description of the specific correction, entered before the invoice returns to the firm. In Unity, rejection reasons come from a pre-defined list managed by admins, and Notify via Email is selected by default so the vendor receives the comments. The firm then sees the code and comment in its eBilling portal, often through the same invoice validation alerts that report rule failures, and can resubmit without a phone call.
A good rejection comment names the line, the rule, and the fix: “Line 14 bills 2.5 hours for a second partner at a meeting; guidelines allow one attending partner. Remove line 14 and resubmit.” A poor one says “rate issue”. The first resolves in one resubmission. The second usually takes two or three rounds.
Clear comments are a large part of how law firms experience your program. Onboarding law firms to eBilling goes smoothly when rejections are predictable and explained, and the comment is often the only explanation a firm’s billing team ever sees.
How do you test mandatory comment logic before go-live?
You test mandatory comment logic by running every trigger action with a blank comment, a placeholder, a comment just under the minimum length, and a valid comment, for every role. For a typical build that is 30 to 60 test cases.
Confirm four outcomes in each case: the action is blocked or allowed correctly, the message explains what is missing, the audit record contains every required field, and the comment cannot be edited after saving. Include the integration points too. A rejection comment that never reaches the firm’s portal, or arrives truncated after 255 characters, fails the purpose of the rule even when the platform screen looks correct.
Test the conditional cases separately. Rules that demand a longer comment only when “other” is selected, or only above a value threshold, rely on conditional logic that basic automation cannot express.
How should mandatory comments be reviewed after go-live?
Mandatory comments should be reviewed monthly for operational workflows and quarterly for exception and override controls, using a report built from the reason codes and comment text. Review is what turns stored comments into governance.
Three measures tell you whether the rule is working:
- Coverage. Every in-scope action carries a reason code and comment. The target is 100 percent.
- Quality. A monthly sample of 20 to 30 comments checked for substance, with a target of 95 percent or higher.
- Exception follow-up. Every high-risk override reviewed by a second person within the month.
If quality slips, check the placeholder blocklist first. Users find new filler phrases, and the list needs updating two or three times in the first year.
Conclusion
Mandatory comments only add value when the platform checks what users write and keeps it in a record that holds up. Limit the requirement to rejections, overrides, exceptions, and controlled changes, pair every comment with a reason code, block filler, and lock the text once saved. Test each trigger by role, then review coverage and quality every month. The result is an audit trail that explains each decision and a law firm that knows exactly what to fix.
How Basla can help
Basla provides delivery teams for enterprise legal management and eBilling software implementation, covering legal technology consulting, business analysis, rejection and exception workflow design, comment and reason-code configuration, testing, documentation, and post-go-live support. Basla business analysts define the trigger actions and comment rules with your team, and the QA team proves each one by role before launch.
Basla has delivered matter management and eBilling programs across more than 10 global jurisdictions, and can scale the delivery bench when timelines compress.
Frequently asked questions
What are mandatory comments?
Mandatory comments are explanations a user must enter before completing a defined action, such as rejecting an invoice or overriding a rule. The platform blocks the action until a valid comment is saved.
What is mandatory comment logic?
Mandatory comment logic is a configured rule that requires a reason code and a substantive comment before a controlled action completes. It validates the content and stores it in a locked audit record.
Which actions should require a comment?
Actions that reject, override, or change a controlled record should require a comment. Typical examples are invoice rejections, validation overrides, exception approvals, and matter status changes.
How do you stop users entering N/A in a required comment field?
A placeholder blocklist stops users entering N/A and similar filler in a required comment field. Pairing it with a template prompt and a short minimum length on high-risk actions keeps comments useful.
Are required comments mandated by SOX?
Required comments are an internal control practice that supports audit evidence, and no blanket SOX rule requires them. Your auditors can confirm which actions your own control framework expects to be documented.
Should comments be editable after they are saved?
Comments should be locked once saved, with any correction stored as a new version. Keeping the original visible preserves the audit trail.
*This article is provided for general information only and does not constitute legal advice. Basla Solutions provides legal technology implementation and support services and does not practice law.*