July 9, 2026

All Q2 balancing payrolls were approved last Thursday, July 2. Any balancing payrolls that resulted in a direct transaction to the employer (either a collection or refund) will begin processing tomorrow. The last chance to cancel these transactions is tonight, July 9th at 11:59 PM ET.

While quarter end balancing was completed last week, in select cases, we may receive feedback from tax agencies at the time of filing regarding incorrect rates set by employers during the period. This feedback can result in corrections to ensure the employer's tax liabilities are correctly adjusted and are performed immediately to unblock filing.

As part of Q2 filing, draft employer copies of the filings will be published tomorrow, July 10. These documents will have draft watermarks on them. If we've already filed a Q2 filing for an employer, the published company document already exists and won't be modified.

Once we complete filing with the agency, the document is published and the draft watermark is removed.

We are placing a held_by_customer blocker on all filings that are currently blocked with a period end prior to Jan 1, 2026.

We are doing this because our system connects some blockers between periods (ie tpa_failure). Removing one of those blockers from a Q2 2026 filing will remove that same blocker from all of the historic filings and queue them for refile, which would result in delayed_filing fees. Historic filings from before 2026 are likely already handled by the customer, so we don’t want to queue them for refile unless explicitly requested.

If you want to refile them, simply remove the held_by_customer blocker (and any other blockers present) in Console or via API.

We’re excited to announce the launch of our Logs API! You can use it to programmatically inspect the requests your integration makes to Check. See the Log object, List logs, and Get a log, along with our new request logs guide.

Each Log captures a single HTTP request made to the Check API, including the path, method, headers, query parameters, request and response bodies, status code, and processing duration, with sensitive values scrubbed before being returned. GET /logs supports filtering by path, method, status code or status class, and a created_after/created_before time range, so you can quickly isolate failing requests when debugging your integration.

Logs are also available through the Check MCP server and CLI, making it easy for your tooling, including AI agents, to inspect request history directly.

Finally, we also refreshed the design of the API Logs table in Console.