Before You Submit an XBRL Filing, Check These Details

An XBRL filing can look complete and still contain errors that need to be resolved before submission. A figure may match the financial statements, but the associated tag, context, period, unit or calculation relationship may not be correct.

This is why the final stage of XBRL preparation should not be treated as a simple upload exercise. Before submitting an XBRL filing, finance teams and compliance professionals need to review both the financial information and the way that information has been structured.

A few checks before submission can help identify issues that would otherwise lead to validation errors or additional rework.

Start by checking the taxonomy and mapping

The first review should focus on whether the reported information has been mapped to the appropriate XBRL concepts.

Financial statements contain many different types of information, including monetary values, percentages, dates, text disclosures and comparative figures. Each relevant fact needs to be represented using the appropriate taxonomy concept and related attributes.

Choosing a concept simply because its name appears similar to the financial statement item can create problems. The meaning of the concept, its period type, data type and other properties also need to be considered.

The applicable taxonomy should therefore be confirmed before the final validation stage. Using the wrong taxonomy or an inappropriate concept can result in errors even when the original financial figure is correct.

Make sure the XBRL data agrees with the financial statements

One of the most important checks is a straightforward reconciliation between the source financial statements and the XBRL data.

Do not check only the final totals. Review the underlying figures and disclosures as well.

Depending on the filing, the review may cover:

• Current-year figures

• Previous-year figures

• Balance sheet information

• Statement of profit and loss

• Notes and schedules

• Relevant disclosures

• Units and currencies

• Dates and reporting periods

For example, if a financial statement shows a particular expense under a specific classification, the corresponding XBRL information should represent the same fact rather than merely using a broadly similar concept.

This reconciliation gives the finance team an opportunity to identify mapping or data-entry issues before the instance document is submitted.

Review reporting periods and contexts

An XBRL fact does not consist only of a number. It also needs the appropriate context.

The context can include information such as the reporting entity and the relevant period.

A value can therefore be numerically correct while still being associated with the wrong reporting period or context.

Comparative figures deserve particular attention. When current-year and previous-year information are both reported, each fact needs to be associated with the correct period.

A final context review can help prevent situations where the number looks correct in isolation but is attached to the wrong reporting information.

Check units, dates and data formats

Technical errors are often easier to overlook than financial inconsistencies.

Numbers, dates, percentages, currencies and other information have to be represented in formats that the relevant XBRL system can process correctly.

For example, the preparer should review whether:

• Monetary values use the appropriate currency

• Dates follow the required format

• Percentages have been entered using the expected scale

• Numerical facts use the appropriate units

• Required fields contain valid values

These checks may seem minor, but a formatting issue can prevent an otherwise complete filing from passing validation.

Don't ignore calculation relationships

Some financial figures have relationships with other figures.

For instance, a total may be expected to correspond with the relevant component values. If the tagged information does not satisfy an applicable calculation relationship, the validation process may identify an inconsistency.

This is why reviewing individual numbers is not enough.

Finance teams should also compare totals with their underlying components and investigate differences before submission. If the difference is intentional, the preparer should understand why the validation result occurs rather than simply treating every warning as a data-entry problem.

Run validation before the final submission

Validation should happen before the filing reaches the final submission stage.

A validation process can identify structural, technical and rule-based problems within an XBRL instance document. It gives the preparer an opportunity to locate the affected information, investigate the cause and make corrections.

The important part is not simply getting a validation result. Each error should be understood before it is corrected.

For example, changing a tag only to remove an error can create a different problem if the replacement concept does not accurately represent the underlying financial information.

A better process is:

Validate → identify the issue → check the source information → review the mapping or context → correct it → validate again.

This creates a more controlled preparation cycle.

Review the final output, not just the validation result

Passing validation does not mean the review is finished.

The final XBRL output should still be compared with the source financial information. This provides another opportunity to identify differences that may not be obvious from a list of technical validation messages.

The review should consider whether the reported information is complete, logically presented and consistent with the underlying financial statements.

This distinction matters because technical validation and financial review serve different purposes. Validation checks whether defined rules and structural requirements are satisfied. Professional review considers whether the information being reported actually represents the company's financial information correctly.

Where XBRL Filing software can help

The preparation process involves repetitive tasks such as importing information, mapping data, tagging disclosures, generating the XBRL instance and running validation checks.

Using dedicated XBRL software can make these activities easier to manage and can reduce some of the manual work involved in preparing the filing.

Webtel's XBRL Filing Software includes functions such as data import, mapping and tagging utilities, error location, XBRL instance generation and in-built validation checks. These types of features can help finance and compliance teams identify issues before the final filing stage.

For teams evaluating software, the important question is not simply how many features a product has. It is whether the workflow makes it easier to move from source financial information to correctly mapped, validated XBRL data.

Cost-XBRL needs its own review process

Cost-XBRL reporting should also be approached according to its specific reporting requirements rather than treated as an identical version of financial statement XBRL.

Where Cost-XBRL reporting applies, the preparation process may involve cost-related information, previous-year data, supporting documents and specific tagging requirements.

Webtel's Cost-XBRL Filing Software provides features including previous-year data import, financial information import from Excel, report import from Word, text-block tagging, validation and cost instance document generation.

For professionals handling cost reporting, checking whether the software supports the required data sources and validation workflow can be useful when evaluating the preparation process.

A practical pre-submission checklist

Before submitting an XBRL filing, the final review can be organised around a few simple questions:

• Taxonomy: Is the applicable taxonomy being used?

• Mapping: Does each important financial fact use an appropriate concept?

• Reconciliation: Do the XBRL values agree with the underlying financial statements?

• Context: Are the entity, reporting period and other context details correct?

• Units: Are currencies, numerical units and percentages represented correctly?

• Calculations: Do applicable totals and component values reconcile?

• Validation: Have all relevant validation errors been investigated and resolved?

• Final review: Does the completed XBRL output accurately represent the source information?

  
  

This approach is more useful than treating validation as the final button to press.

The final check should go beyond "Does it validate?"

A successful XBRL filing depends on more than producing a technically valid document.

The information needs to be mapped appropriately, associated with the correct context, represented in the required format and reconciled with the underlying financial statements.

That is why the final review should ask two questions:

Does the file satisfy the applicable XBRL requirements?

And:

Does it accurately represent the information being reported?

When both questions have been addressed, the submission process becomes much more controlled. Instead of discovering problems at the last stage, finance teams can identify mapping, data and validation issues while there is still time to investigate and correct them.