1099-HC Electronic File Preflight for Massachusetts Reporting

Use DOR’s bulk-file instruction index to locate the handbook, schema and current portal guidance. Record the reporting year, document revision, download date and exact schema reference used. Keep the final package reproducible from those inputs.

The currently linked 1099-HC handbook has a January 2019 printed revision and a version 2.4 schema diagram. Treat those as observed document identifiers, not proof that future production should use an old cached schema without checking.

Confirm the intended filing account and authorized submitter. Preparation staff can validate a file without having authority to transmit it. Keep the release decision and filing responsibility explicit in the runbook.

Check that the output is an actual XML document using the expected structure, encoding and namespace. Renaming a CSV file with an .xml extension does not create a state filing file. Use an XML parser followed by validation against the current DOR schema.

Review required elements, element order, field lengths, allowed values and real calendar dates. Preserve the validator version and result. A local validation failure should identify the record and field so the data or mapping can be repaired at its source.

The DOR bulk-filing guidance says 1099-HC bulk files must be XML and identifies a 250-megabyte MassTaxConnect upload limit. Check the current limit before release and plan file handling through the documented process; splitting XML bytes arbitrarily will not produce valid independent documents.

Confirm company identifiers and names, subscriber uniqueness, dependent relationships and coverage spans. Check that each record belongs to the intended reporting year and that the MCC classification comes from the approved plan evidence.

A correctly formatted subscriber number can still point to the wrong person. A valid start and end date can still come from the wrong enrollment period. Reconcile selected records against the source system and include edge cases such as reinstatements and dependent changes.

The DOR carrier rules require consistency between state data and subscriber statements and define covered MCC months using the 15-day threshold. Keep these factual checks separate from schema success so an XML pass does not hide a statement discrepancy.

Fictional example: A test file contains three deliberately defective records. The internal preflight reports the following findings; these labels are invented for the example and are not DOR error codes.

The third issue could survive a structural XML check because the date fields themselves are valid. The team therefore records separate technical, relationship and statement-comparison results. All affected outputs are regenerated after the source repair, rather than hand-editing one delivered copy.

Create a manifest identifying the final file, reporting company, year, subscriber count and source snapshot. Compare record identities as well as totals with the recipient statement dataset. A count of one hundred on both sides can conceal different missing and extra people.

The handbook notes that some document-count and identifier attributes are not validated by DOR. Maintain your own completeness check rather than assuming every declared control value will be enforced by the receiving system.

Preserve correction and deletion flags with their reviewed reasons. Keep original and corrected records distinguishable in the manifest. A generic retry of an uncertain submission can create duplicate reporting if the first file was already processed.

Assign a person to capture the submission reference, file version, date and MassTaxConnect response. DOR’s current guidance says file exceptions are communicated through e-messages in the account. Include that review in the checklist before the submitter begins.

Keep “prepared,” “submitted,” “response reviewed” and “exceptions resolved” as distinct operational states. They are internal tracking labels, not claims about exact portal status names. An upload confirmation alone does not establish that every record is correct.

For an exception, preserve the actual message, affected record, source repair and subsequent response. Reconcile any corrected recipient output with the state change. Close the batch only after the responsible reviewer has documented the actual outcome.