Convert your annual report to a validated iXBRL package.

During the intake, we confirm the reporting entity, reporting period, filing authority, submission destination and applicable accounting or reporting framework. We also establish the required taxonomy and taxonomy version, the tagging scope, the source format, the expected Report Package structure and the filing deadline.

At this stage, we agree how the project will be managed. This includes identifying the people authorised to approve taxonomy and mapping decisions, defining how review comments will be handled and determining how late changes to the source report will be incorporated. Where filing support is required, the responsibilities of Semansys and the reporting organisation are documented in advance.

The source report is also assessed for complexity. We review its length, structure, languages, financial statements, notes, tables, typography, images, internal references and entity-specific disclosures. Reports with complex multi-column layouts, extensive graphics or highly designed tables may require additional preparation to function correctly in a browser-based filing environment.

The outcome of the intake is a documented scope, delivery schedule and commercial proposal. This creates clarity before production begins and reduces the risk of late-stage surprises.

The source report is assessed for conversion readiness and prepared for controlled transformation into XHTML. The objective is not simply to recreate the appearance of the original file. The XHTML document must also contain a logical reading order, usable navigation, properly structured tables and content that can be tagged and processed reliably.

During this phase, headings, paragraphs, tables, images, footnotes, internal links and other presentation components are converted while preserving the report’s approved content and visual identity as closely as the applicable filing rules permit.

Special attention is given to elements that do not always translate cleanly from print or PDF into XHTML. These can include complex tables, multiple columns, special characters, page-dependent references, custom fonts, embedded graphics and content positioned for a fixed-page layout.

Where necessary, small presentation adjustments are discussed with the client. The objective is to maintain the communicative integrity of the annual report without introducing fragile XHTML or elements that conflict with filing requirements.

The result is a human-readable XHTML report that forms the presentation layer of the final iXBRL filing.

We use standard taxonomy concepts wherever they faithfully represent the accounting or reporting meaning of the disclosure. A concept is not selected simply because its label resembles the wording in the annual report. Its definition, accounting meaning, period type, data type and relationships within the taxonomy must also be appropriate.

Where the reporting framework permits entity-specific extensions, these are introduced only when no suitable standard concept is available. Extensions are therefore treated as controlled reporting decisions rather than convenient alternatives to taxonomy analysis.

Depending on the filing regime and agreed tagging scope, the process may cover monetary and non-monetary facts, dates, percentages, shares, text facts, narrative disclosures, accounting policies, primary financial statements, explanatory notes and detailed tables. Depending on the filing regime, it may also include extension taxonomies, presentation relationships, calculation relationships, dimensional structures and anchoring.

For each tagged fact, we determine the relevant concept, reporting entity, period, unit, format, decimals, scale, sign and dimensional context, where applicable. These properties are fundamental to the meaning of the extracted data. A visible value can appear correct while the underlying structured fact contains the wrong period, scale or sign.

This is therefore a semantic process rather than a simple text-matching exercise. The objective is not to apply the greatest possible number of tags. It is to create the most accurate structured representation of the report within the applicable taxonomy and filing rules.

Material, unusual or judgement-sensitive mappings are identified for focused review with the client.

Structural validation verifies that the Inline XBRL documents and supporting files conform to the relevant XHTML, Inline XBRL and XBRL specifications. Taxonomy validation examines the schemas, linkbases, relationships, concepts and extension components included in the package.

The report is also checked against the technical and business rules published for the relevant filing framework or receiving authority. These filing rules may address naming conventions, permitted files, report-package structure, taxonomy entry points, tagging obligations, prohibited content and other authority-specific requirements.

Fact and context validation assesses the properties that determine the meaning of the structured data. This includes contexts, units, reporting periods, dimensions, scales, signs, decimals and duplicate facts. Calculation and consistency checks are used where applicable to identify relationships that do not reconcile as expected. A calculation inconsistency is treated as a review signal and does not by itself prove that the visible financial statements are incorrect.

Automated semantic and business-rule checks are supplemented by expert review. This is important because a report can pass a basic technical validator while still containing a poorly selected concept, an unnecessary extension or a fact that does not represent the approved disclosure correctly.

The rendered report is also compared with the source document. We review tables, headings, footnotes, special characters, internal navigation, links, images and the visibility of tagged facts. Package-level checks confirm that the required files are present, internal references resolve correctly and prohibited or unnecessary resources have not been included.

Validation findings are classified according to their severity. Blocking errors are distinguished from warnings and review points that require professional judgement. Passing a validator is an important control, but it is not treated as proof that every semantic and presentation decision is correct.

The finance, accounting or reporting team can compare the visible iXBRL report with the approved source and review the structured treatment of material disclosures. Particular attention is generally given to significant line items, entity-specific reporting, extension concepts, changed accounting treatments and disclosures that required judgement during mapping.

Where appropriate, Semansys provides supporting information on taxonomy decisions, extensions, validation findings and open review points. Technical validator messages are translated into clear reporting consequences so that the client can make informed decisions without having to interpret low-level XBRL diagnostics.

Comments are processed through a controlled remediation cycle. Changes are applied to the XHTML, tagging or taxonomy components as required, after which the affected elements are validated again.

Annual reports often continue to change during audit, governance approval and final publication. Where the underlying source report is revised, Semansys assesses the changes and updates the iXBRL report through the agreed change-control process.

This ensures that the final package reflects the approved report rather than an outdated production version.

Depending on the applicable filing framework, the package may include one or more XHTML or Inline XBRL documents, extension-taxonomy schemas, presentation and calculation linkbases, definition and label linkbases, permitted images, stylesheets, fonts, package metadata and other supporting resources.

Before release, we confirm that the final content corresponds with the approved source, that the agreed taxonomy and taxonomy version have been applied and that all approved review comments have been processed.

We also confirm that the agreed validation procedures have been completed, the package structure meets the applicable requirements and the delivered package is the version intended for submission.

The completed filing package is delivered through the agreed secure channel, together with any validation or delivery documentation included in the scope.

This support may include a final pre-filing package check, assistance during upload or submission, interpretation of filing-portal messages and analysis of authority-generated errors or warnings.

Where a receiving system identifies an issue, Semansys can investigate whether the cause lies in the report, taxonomy, package structure or authority-specific validation rules. Where remediation is required, we can produce and validate a revised Report Package through a controlled release process.

The precise responsibilities for filing are agreed during the intake. Unless explicitly included in the service scope, the reporting organisation remains responsible for authorising and completing the statutory submission.

Acceptance by the receiving authority remains subject to the authority’s own systems, controls and filing procedures.