1094-C Software Permissions and Approval Workflow Checklist

Describe the work before naming the roles. Preparation includes importing source data, reviewing entity settings and changing draft transmittal fields. Approval confirms that an identified version has completed the employer's review. Release makes that approved version available for the actual transmission process. Some products combine these actions; the evaluator should understand exactly what a button does.

For the reporting context, the 2025 instructions require one authoritative transmittal for each ALE Member. Make changing that selection a specific permission in the demonstration because it changes where the employer-level summary is reported. A general edit permission may cover it, but the team should observe that behavior.

An internal approval is not automatically the form's signature or authorization to act for the employer. Ask the vendor to explain the separate roles and records used in its actual filing process.

This matrix is a starting point, not a claim that all products have these role names. Where one employee holds several roles, document which decisions still require another person and how the product supports that separation. Test export permissions independently if the organization wants some reviewers to inspect summaries without downloading employee-level data.

Create approved synthetic data for two employers in a nonproduction environment. Give the preparer access to only one employer, then perform an allowed edit through the normal interface. Next attempt the corresponding action on the other employer and record the actual result. Do the same for approval, export and release as relevant to the purchased workflow.

A hidden button alone does not establish that the underlying action is restricted. Ask the vendor to demonstrate the normal supported route for that action using the restricted account and show the resulting denial or enforced boundary. Keep this a product demonstration with authorized test accounts, not an attempt to probe an unapproved system.

Record scope changes too. If a user moves teams, demonstrate removal of the old employer access and assignment of the new scope. Reopen the relevant workflow using that account so the evaluator can see whether the new permissions take effect as expected.

Fictional example: Ridge Assembly's preparer creates 1094-C draft v3 with a June full-time employee count of 87. A reporting reviewer examines the source reconciliation and approves v3. Before release, the preparer receives a reviewed source correction and changes that count to 88, creating v4.

The evaluation's expected control is that approval of v3 does not silently become approval of v4. Ask the release operator to continue through the normal demonstration path. The product might require a new approval automatically, or the employer might need a documented manual hold and second review. Record which process was actually shown.

The reviewer then compares v3 and v4, verifies the single changed count and approves v4. The release operator should be able to identify v4 as the version selected for the next step. Keep both approvals and their version references. An audit entry saying approved, without identifying what was approved, cannot explain this sequence.

Ask how the team covers an absent reviewer without sharing an account. Demonstrate the substitute's assigned scope and confirm that the resulting action records identify the actual person who performed it. If the workflow permits an override, ask who may use it, what reason is captured, and how someone else later discovers that the normal sequence was bypassed.

Test whether an access administrator can grant themselves release permission, and document the observed behavior. The purpose is to understand the control and its review process, not to presume that every product uses the same administrative model. An emergency path should be an explicit decision in the evaluation, not an undocumented surprise during filing season.

Keep automation identities separate in the demonstration notes. If an integration imports or releases work, ask how the product identifies that operation and connects it to the organization's approval procedure. Do not infer human approval merely from the presence of an automated event.

Request a demonstration export containing employer, reporting year, version, relevant changes, approver identity, approval time and release action. Then locate the transmission outcome separately. Publication 5165 explains that receipt and acknowledgment evidence have different roles; a local release event does not by itself establish AIR acceptance.

Hand the evidence to a colleague who missed the session and ask them to reconstruct the Ridge Assembly example. They should be able to determine that v3 was approved, v4 changed the June count, and the later approval applied to v4. Record any gap between what the screen showed and what the export preserves.

Use the software evaluation scorecard to capture the demonstrated result and dependencies. Keep a short implementation checklist for role setup and substitute coverage so the demonstrated controls are actually configured when the employer begins using the product.