Who this guide is for

This guide is for technical evaluators rather than directors looking for a simple filing product. It is aimed at software founders, AI workflow builders, accountancy firms with internal automation teams, and integrators deciding whether Robocount can support API-led or agent-assisted CT600 preparation.

The commercial question is straightforward: can AI help prepare and review Corporation Tax work without weakening security or auditability? The answer depends on the controls around the return package, not only on the quality of the model.

Why CT600 controls matter

HMRC's Corporation Tax online environment is structured. The Company Tax Return package can include the CT600, accounts, computations, supplementary pages, and attachments. Developer guidance and technical specifications exist because the filing process is not just a human-readable form.

AI workflows add another layer of risk. An agent can gather facts quickly, but it can also misunderstand source data, skip an attachment, overwrite a reviewed figure, or expose sensitive data in logs. Product controls are the difference between useful automation and filing activity the firm cannot secure, audit, or explain later.

Keep AI suggestions separate from the return record

The core design principle is simple: AI output should not become the tax return just because it sounds plausible. Let AI suggest, explain, classify, and draft. The product should decide whether the return package is complete enough for review.

Keep company details, accounting periods, computations, attachments, approvals, and supplementary-page decisions in structured return fields rather than loose chat output.
Record the source for each material figure: import, uploaded file, user entry, or reviewer adjustment.
Require explicit reviewer acceptance for AI-suggested classifications or tax-sensitive mappings.
Prevent submission if required fields, attachments, or approval events are missing.

Control layers for a CT600 API

A serious CT600 API should check the return at several levels before a Government Gateway submission is attempted. These checks make the workflow easier for a practice to trust, review, and explain.

Return data checks: required fields, accounting-period dates, company details, and allowed values are present before review starts.
Computation checks: tax calculation consistency, relief ordering, loss usage, and marginal relief checks where relevant.
Return-package checks: CT600, accounts, computations, supplementary pages, and attachments are present and aligned.
Approval checks: preparer review, manager approval, client approval, and submission authority are recorded.
Security checks: credentials, tokens, permissions, and sensitive identifiers are kept away from model prompts and uncontrolled logs.
Audit checks: material changes, approvals, submissions, rejections, and resubmissions can be traced back to a user, time, package version, and source evidence.
Filing checks: the final package is locked, HMRC response handling is ready, and rejection paths preserve the original evidence.

Tool boundaries for CT600 agents

Agent workflows are safest when each tool has a narrow job. Whether the integration uses MCP or another API pattern, the agent should not have unrestricted access to change and submit a Corporation Tax return.

Read tools: inspect company details, accounting period, uploaded accounts, computation summary, and review status.
Draft tools: create proposed mappings, supplementary-page triage notes, and follow-up questions.
Validation tools: run repeatable checks and return clear errors or warnings.
Approval tools: record human decisions, not infer them from chat context.
Submission tools: remain gated behind explicit approval and complete package validation.

Supplementary-page triage controls

Supplementary pages are a natural AI triage task, but the output should be conservative. The agent can flag possible CT600A, CT600C, CT600L, CT600N, CT600P, or other supplementary-page triggers, then require human confirmation before the page is included or excluded.

Every exclusion should be explainable. If the accounts show a director loan balance but CT600A is not included, the workflow should show why. If a group relationship exists but CT600C is not attached, the reviewer should be able to see that no claim or surrender was made.

iXBRL and attachment checks

Online CT600 filing depends on the return package, not only field values. HMRC guidance and XBRL material explain that accounts and computations are part of the electronic filing environment. A validation workflow should therefore check the attachment state before approval.

Which accounts file is attached?
Which computation file is attached?
Do the approved computation totals match the CT600 values?
Were accounts or computations changed after approval?
Is there a clear reason where a PDF attachment route is used instead of iXBRL?

Security, audit logs, and evidence

CT600 workflows include sensitive company and tax data. Security and audit controls should prove what happened without creating a second uncontrolled data store.

Do not log Government Gateway credentials, software identifiers, access tokens, or private operational identifiers.
Avoid storing full client source documents in model prompts or debug logs.
Redact unnecessary UTRs, account numbers, and direct identifiers from support exports.
Keep HMRC response evidence and rejection messages in the secure return record, not loose chat transcripts.
Record who changed, reviewed, approved, submitted, amended, or resubmitted the return, without exposing secrets used to operate the filing route.

Human approval should be an explicit event

A chat message like "looks fine" is not enough for a tax filing workflow unless the product turns it into a deliberate approval event with the approved return package attached. The approval should identify the package version, the reviewer or client, the time, and anything that changed afterwards.

If an AI agent changes a material figure after approval, the workflow should require a fresh review. That is especially important for amended returns, rejected submissions, and any case where attachments are regenerated.

How Robocount approaches API and MCP validation

Robocount is built around structured CT600 preparation, review, validation, security, audit, and filing readiness. Its API and MCP direction is designed for teams that want AI-assisted workflows without hiding the Company Tax Return package from the people responsible for it.

Structured CT600 workflow instead of free-form chat-to-form filling.
Supplementary-page review tied back to the main return.
Clear approval and evidence concepts for practice and director workflows.
Security and audit controls that keep sensitive filing data out of uncontrolled prompts and logs.
Automation boundaries that support AI assistance without hiding reviewer accountability.

FAQ

Can a CT600 API rely on AI validation alone?

No. AI can help identify issues, but a filing workflow needs repeatable product checks for required fields, package completeness, attachments, approvals, and submission status.

What should an MCP CT600 tool never expose?

It should not expose credentials, secret operational identifiers, raw filing keys, unnecessary client identifiers, or unrestricted submission actions. Filing should be gated and auditable.

Why does audit matter in AI-assisted CT600 filing?

Because the firm still needs to explain who changed the return, which package was approved, what was submitted, and how any rejection or amendment was handled. AI can assist the work, but the audit trail must remain human-reviewable.

How should rejected CT600 submissions be handled?

Preserve the original package and HMRC response, fix the specific issue, re-run validation, collect any required approval, and retain the resubmission evidence.

Why are attachments part of API validation?

Because a Company Tax Return package can include accounts and computations as well as the CT600. Field-level validation is incomplete if the approved attachments are missing or mismatched.

Useful official references

This guide is general product and developer workflow information, not tax advice or HMRC technical implementation guidance. Build against current HMRC specifications and test requirements.

CT600 API security and audit controls for AI tax filing workflows.