Integrated structured reporting method and systems

Abstract

The present application discloses integrated structured reporting methods and systems. There is provided a computer-implemented method for generating an electronically publishable structured document, wherein generation of the document is performed using an XHTML platform. The method comprises on the XHTML platform, generating a draft document by: generating content comprising at least one of i) written text ii) a table for storing numerical data, and iii) graphical elements; generating a plurality of XBRL tags, and assigning each XBRL tag to a portion of the content; and generating a persistent association between each assigned XBRL tag and its respective content portion, wherein the persistent association is visible to a user editing the draft document on the XHTML platform, and wherein the persistent association defines a position of the XBRL tag relative to the assigned content portion in the subsequently published document. The method then comprises exporting the draft document comprising the plurality of XBRL tags and the persistent associations to obtain at least one structured document having at least one respective electronically publishable format, the format being one or more of: HTML, xHTML, and PDF.

Description

[0001] RWR01-133927PC

[0002] INTEGRATED STRUCTURED REPORTING METHOD AND SYSTEMS

[0003] CROSS-REFERENCE TO RELATED APPLICATION

[0004] This application claims priority from UK patent application GB2418614.0 filed on 18 December 2024, which is herein incorporated by reference in its entirety.

[0005] TECHNICAL FIELD

[0006] This disclosure relates to the generation of structured digital reporting documents, in particular to a method of producing and validating an electronic structured report that uses XHTML and XBRL (known as Inline XBRL or iXBRL for short).

[0007] BACKGROUND

[0008] Listed businesses are required to publicly disclose their finances annually. Increasingly these financial disclosures must be reported in a structured digital format (i.e., a ‘structured report’ in iXBRL - an XHTML formatted report with XBRL tags applied). These mandatory structured digital reports use standardised ‘taxonomies’ and are prepared specifically to facilitate access, analysis and comparison with other businesses’ reports. The use of structured reports, in particular reports in a digitally accessible format, thus enhances public transparency of listed business’ disclosures by improving the technical facilities by which structured digital reports can be viewed, stored, and compared. However, this goal may only be achieved if businesses can effectively produce structured reports in a compliant and digitally accessible format, and only if businesses can do so reliably and efficiently within a reasonable timeframe. Furthermore, creating and publishing annual reports puts a great burden on businesses, who must deal with the technical challenges of collaboratively generating, reviewing, and revising the report in the desired format. This is time-consuming for businesses, and moreover consumes large amounts of computing resources. These new structured digital report format requirements place an even greater burden of complexity on companies. Current structured reporting generation typically depends upon very limited and immature software available for its creation, which is often not fit for purpose. Thus, known structured reporting software suffers from many technical limitations, which, in addition to being non-accessibility compliant, may not be capable of generating structured reports that can be stored, compared, cr edited in an efficient way. Structured reports are published by thousands of companies, and current software limitations make the reports excessively large, difficult to edit and publish, unusable by audiences, and not fully compliant with the intended accessibility and tagging regulations.

[0009] Typically, most businesses currently take a ‘bolt-on’ (non-integrated) approach when producing their structured digital annual reports. The reports are first written and designed in print / PDF format, and then converted to the iXBRL format (XHTML + XBRL). Currently this still means generating a written report using document or print design software (Word or InDesign). Although these tools may be configured to assimilate and consolidate relevant financial information and permit collaborative generation, they can only produce a basic print-like PDF RWR01-133927PC document, not a fully compliant digital report in XHTML. This PDF file is not the format required for technical and publication compliance, and moreover is technically very difficult to edit, difficult to publish in a widely accessible way, and can consume computer storage inefficiently. Thus, the initial PDF document then needs to be converted to the required digital format (e.g. xHTML). Due to the intrinsic ‘unstructured’ limitations of PDF, this conversion from PDF to the required XHTML format still fails to generate an accessible, efficiently storable, and efficiently editable document. Specifically, the electronic format created by the conversion from PDF to XHTML is not a truly digital format (e.g., it is not technically suitable for online accessibility and may not be rendered correctly on many browsers and devices) and does not include all the technical attributes required in the mandatory structured digital format. This converted file is often excessively large (e.g., often more than 70- 80 MB in size). Regulators (e.g., FRC) and standards setters (e.g., XBRL International) publicly recognise these limitations are in software only and not limitations of the format specification. It is therefore an objective of the present disclosure to provide means to address these limitations.

[0010] Yet further, the XHTML document needs to be ‘tagged’ with the relevant taxonomy labels, e.g., XBRL tags (XBRL, Extensible Business Reporting Language, being a standardized language that permits accurate labelling and automated comparison of business text and data). To comply with evolving regulations, a single report may eventually contain thousands of individual XBRL tags. The current method of conversion from PDF to XHTML presents many problems with XBRL tagging, in process, quality, compliance and usability.

[0011] One problem is the difficulty in tagging (e.g., using iXBRL tags) the converted report and re-tagging revisions of the report. Typically, reports are tagged only after being converted into the desired electronic publication format (e.g., XHTML). Multiple revisions of the underlying document are performed subsequent to the tagging, and then the tags also need to be manually revised. Selecting and applying the tags is a specialist job requiring suitable experience and expertise, for example in technical accounting standards, and how to use a tagging tool to correctly tag the document. In current methods, the application of a text tag does not persist reliably when a revised PDF proof of the document is re-converted to XHTML because each new iteration needs to undergo the conversion process from scratch (and the tags were applied to the converted document, not the original). Thus, tagging may need to be repositioned or even started from scratch for each new proof iteration. Other problems such as cross-referencing of portions of the text and tags, using known methods, is necessarily a manual task when the bolt-on process is used, thus making it very time-consuming and error-prone. Moreover, known processes for revising XBRL tagging necessitate wasteful use of computing resources, due to the lack of text positioning persistence when a PDF proof of the document is re-converted to XHTML.

[0012] Another fundamental problem using the bolt-on PDF conversion method (e.g., from PDF to XHTML) which causes universal difficulty across thousands of reports, is that the resulting tagged document can be very unwieldy (e.g., often more than 70 MB in size). This causes problems with data analysis, internal and external dissemination, online loading and usage, data validation, data extraction and processing, storage, uploading and downloading of the report. For example, the tagged document, or a set of such tagged documents, undesirably occupies memory and bandwidth resources. This large file size is caused by the conversion process RWR01-133927PC from a PDF’s pixel-level encoding of the content positioning and is an intrinsic flaw using the PDF as a source of XHTML.

[0013] There currently exist tools which individually and separately perform some of the tasks described above. However, the lack of integration of crucial functions, and the lack of digital-first solutions for creating the XHTML format make the currently available tool and processes slow, inefficient, resource-intensive (both computationally and in terms of human resources), fragmented and not digitally accessible or compliant.

[0014] In summary, the PDF-to-XHTML process produces not only large files but produces reports with restrictive data quality and digital code that does not comply with accessibility legislation, i.e., the produced files are not technically compatible. For example, they cannot be viewed by all electronic devices and cannot be published for easy online access and use. In general, the process of preparing a structured report using the PDF-to- XHTML conversion (e.g., ‘bolt-on’) method, and the process of engaging with and reviewing the finalised structured report, results in very poor human-machine interaction. The aforementioned processes are thus wasteful of computing processing resources, computing storage, and networking resources alike. No known XBRL software can solve these combined problems. Specifically, because of the way in which XHTML documents are generated, the problem arises fundamentally before any tags are applied, because the method itself, and the source (i.e., PDF) of XHTML documents produced by known methods, are not fit for the purpose.

[0015] The present disclosure seeks to mitigate or entirely overcome the problems explained above.

[0016] The embodiments described below are provided by way of example only and are not limiting of implementations which address any or all of the disadvantages of known methods and apparatuses which generate structured reports.

[0017] SUMMARY

[0018] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description.

[0019] According to the present disclosure there is provided a computer-implemented method for generating an electronically publishable structured document, wherein generation of the document is performed using an XHTML platform, the method comprising: on the XHTML platform, generating a draft document by: generating content comprising at least one of i) written text ii) a table for storing numerical data, and iii) graphical elements; generating a plurality of XBRL tags, and assigning each XBRL tag to a portion of the content; generating a persistent association between each assigned XBRL tag and its respective content portion, wherein the persistent association is visible to a user editing the draft document on the RWR01-133927PC

[0020] XHTML platform, and wherein the persistent association defines a position of the XBRL tag relative to the assigned content portion in the subsequently published document; exporting the draft document comprising the plurality of XBRL tags and the persistent associations to obtain at least one structured document having at least one respective electronically publishable format, the format being one or more of: HTML, xHTML, and PDF.

[0021] Preferably, the electronically publishable format is one of native HTML, native xHTML, and HTML-based PDF. The persistent association can advantageously ensure that inline XBRL tags are kept in the correct position, i.e., associated with the correct content portion of the document, when published, irrespective of removals or additions of content at other parts of the document. Further advantageously, the draft document can be simultaneously exported into a plurality of different output formats to obtain a plurality of structured documents each having a different format: e.g., a PDF and an xHTML file can be created simultaneously.

[0022] According to the present disclosure there is also provided a computer-implemented method for generating an electronically publishable structured document, wherein generation of the document is performed using XHTML on a content management system, CMS, the method comprising: on the CMS, generating a draft document in an XHTML format by: generating content comprising at least one of i) written text ii) a table for storing numerical data, and iii) graphical elements; generating a plurality of XBRL tags, and assigning each XBRL tag to a portion of the content; generating a persistent association between each assigned XBRL tag and its respective content portion, wherein the persistent association is visible to a user editing the draft document on the XHTML platform, and wherein the persistent association defines i) a positional relationship between each XBRL tag and its respective content portion that is configured to respond to edits of the content of the draft document and ii) a position of the XBRL tag relative to the assigned content portion in the subsequently published document; exporting, using the CMS, the draft document comprising the plurality of XBRL tags and the persistent associations from the XHTML format to obtain a plurality of structured documents each having a different format, including at least one electronically publishable format and at least one print format, the electronically publishable formats comprising at least: XHTML, and PDF.

[0023] In example implementations, the CMS is configured to enable a plurality of design controls for written text and for cells forming part of a table, wherein the plurality of design controls comprise: paragraph text styles in cells, hyperlinks in cells, super-scripts or sub-scripts in cells, and typographic design including spacing, colour, and fonts. In example implementations, the draft document comprises one or more graphical elements, wherein the CMS is configured to design and encode each graphical element using CSS, wherein the design of the graphical element is thereby preserved in each of the print format and the electronically publishable formats.

[0024] Thus, advantageously, and as described in the following description in more detail, at least these features can provide at least the following functionalities: Advanced cell-styles functionality (e.g., complete design controls RWR01-133927PC on financial tables in HTML and / or XHTML); Full typographic design controls for paragraphs and characters styles (including letter spacing, word spacing and micro-level line-spacing / leading, and the like); Complete page layout functionality (including HTML flex box, grids, multi-level containers, blocks); Complete custom / bespoke CSS design controls at every level of CSS hierarchy, and on every designed element; Fully responsive behaviours for both layout containers and content blocks.

[0025] In example implementations, the method further comprises: generating a table in the draft document, and assigning at least one XBRL tag to a portion of the table; obtaining numerical data from a source external to the HTML platform; and populating the table with the obtained numerical data. In some example, wherein the table can be formatted and tagged prior to populating the table with the numerical data. This advantageously allows for the generation and editing of the numerical data to be performed in parallel with, or prior to, the generation of the draft document’s formatting, structure, and tagging. This also advantageously allows for the format of preexisting reports to be reused for new numerical data, since there is a persistent link between the XBRL tag and the portion of the table to which it is assigned. Thus, the tables can be pre-tagged is irrespective of, and independently from, the numerical content that ultimately populates the tables.

[0026] In example implementations, the method further comprises: prior to exporting the draft document, validating an accuracy of the draft document comprising generating an error flag indicating i) an error type and / or ii) a location of the error within the document, wherein the accuracy of the draft document pertains to one or more of: an accuracy of the HTML code, an accuracy of an XBRL tag, and an accuracy of a numerical entry in a table within the draft document.

[0027] In example implementations, validating the accuracy of the draft document comprises determining a technical correctness of one or more XBRL tags, the determining comprising, for each of the one or more XBRL tags: determining a concept and / or type of the XBRL tag; determining that a mismatch exists between a concept and / or type of the content portion to which the XBRL tag is assigned; generating the error flag in response to the determination of the mismatch.

[0028] In example implementations, the method further comprises : generating one or more further XBRL tags and assigning the one or more further tags to a block of content, wherein the block of content is a content portion to which at least one tag, of the plurality of XBRL tags, has already been assigned; wherein the one or more further XBRL tags are different to the already assigned at least one tag.

[0029] In example implementations the method further comprises, on the HTML platform and prior to exporting the draft document: including a cross-reference indication in a portion of the content, the cross-reference indication indicating one or more content portions of the draft document; RWR01-133927PC generating a persistent cross-reference association between the cross-reference indication and each of the one or more content portions, wherein the persistent cross-reference association is configured to define a relationship with of each of the one or more content portions in the subsequently published document.

[0030] In example implementation, the HTML platform is an xHTML platform, the electronically publishable format of the structured document is xHTML, and the written content and the plurality of XBRL tags are electronically searchable in the obtained structured document.

[0031] In example implementations, the method further comprises, on the XHTML platform and prior to exporting the draft document: generating one or more further XBRL tags; assigning each of the one or more further XBRL tags to a subset of a content portion, wherein the content portion has already been assigned an XBRL tag of the plurality of XBRL tags; generating a persistent association between i) the further XBRL tag and the subset of the content portion, and between ii) the further XBRL tag and the already-assigned XBRL tag. In some examples this further XBRL tag is a nested XBRL tags, e.g., a micro tag for a table entry within a table that is itself XBRL tagged.

[0032] In example implementations, the already-assigned XBRL tag is assigned to a table for storing numerical data, and the one or more further XBRL tags are assigned to respective cells or data entries within the table.

[0033] In example implementations, the method further comprises: after assigning each XBRL tag to a content, displaying, on a graphical user interface within the draft document, a fact value of each of the assigned XBRL tags.

[0034] In example implementations, the method further comprises, on the HTML platform and prior to exporting the draft document: determining a concept and / or a type of a plurality of assigned XBRL tags assigned to content portions containing a numerical value; determining that an error exists in a value or sign of a numerical value in dependence on the concept and / or type of the XBRL tag assigned to that value; in response to determining the mismatch, indicating or applying a correction to the value or sign of the numerical value. In this way, automatic logic may correct a value type based on the tag type defined by the taxonomy (e.g., if the default sign for certain types of financial reporting figures is negative or positive).

[0035] In example implementations, the method further comprises: subsequent to generating each of the persistent associations between each assigned XBRL tag and its respective content portion, editing a portion of the content to obtain an edited draft document; exporting the edited draft document to obtain an edited structured document in electronically publishable format, wherein the edited structured document comprises the persistent associations, and wherein a position of each assigned XBRL tag in the edited structured document is co-located with its respective content RWR01-133927PC portion in dependence on the persistent associations. In this way, the XRBL tags may move with the content to which they are assigned, thus obviating the need to re-tag the document during revisions of the content.

[0036] There is also provided A computer program comprising a program code for performing any of the disclosed methods when executed on a computer.

[0037] There is also provided a system for generating an electronically publishable structured document, the system comprising one or more processors and an XHTML platform for generating a draft document, the system further configured to: receive input to thereby generate content comprising at least one of i) written text and ii) a table for storing numerical data; receive input to thereby generate a plurality of XBRL tags, receive input to assign each XBRL tag to a portion of the content; generate a persistent association between each assigned XBRL tag and its respective content portion, wherein the persistent association defines a position of the XBRL tag relative to the assigned content portion in the subsequently published document; display the persistent association to a user using the HTML platform, and export the draft document comprising the plurality of XBRL tags and the persistent associations to obtain at least one structured document having at least one respective electronically publishable format, the format being one or more of: HTML, xHTML, and PDF.

[0038] In example implementations, the system further comprises a memory storing an XBRL taxonomy module, the XBRL taxonomy module including one or more of: an XBRL extension taxonomy having XBRL extension taxonomy concepts and / or types, and an XBRL base taxonomy having related XBRL base taxonomy concepts and / or types.

[0039] There is also provided a computer-implemented method for generating an electronically publishable structured document containing graphics, wherein generation of the document is performed using an XHTML platform, the method comprising: on the XHTML platform, generating a draft document by: generating content comprising at least one graphic, the graphic comprised of a plurality of graphical elements and represented using HTML and / or CSS; generating a plurality of XBRL tags and, using the generated plurality of XBRL tags, assigning an XBRL tag to the graphic and assigning at least one XBRL tag to at least one respective graphical element within the graphic; generating a persistent association between each assigned XBRL tag and its respective portion of the graphic, wherein the persistent association is visible to a user editing the draft document on the XHTML platform, and wherein the persistent association defines a position of the XBRL tag relative to the assigned portion of the graphic in the subsequently published document; RWR01-133927PC exporting the draft document comprising the plurality of XBRL tags and the persistent associations to obtain at least one structured document having at least one respective electronically publishable format, the format being one or more of: HTML, xHTML, and PDF.

[0040] In example implementations, each graphical element may be formed of content selected from one or more of: text; tabular content; and an image.

[0041] In example implementations, generating the draft document further comprises: generating content comprising at least one of i) written text and ii) a table for storing numerical data; generating a further plurality of XBRL tags, and assigning each generated XBRL tag to a portion of the content; generating a persistent association between each assigned XBRL tag and its respective content portion.

[0042] In example implementations, generating the draft document comprises providing a graphical user interface and performing, by an end user using the graphical user interface, the steps of generating the content, generating the plurality of XBRL tags, and assigning the generated XBRL tags.

[0043] There is also provided a system for generating an electronically publishable structured document containing graphics, the system comprising one or more processors and an XHTML platform for generating a draft document, the system further configured to: receive input to thereby generate content comprising at least one graphic, the graphic comprised of a plurality of graphical elements and represented using HTML and / or CSS; receive input to thereby generate a plurality of XBRL tags; receive input to assign, using the generated plurality of XBRL tags, an XBRL tag to the graphic and assign at least one XBRL tag to at least one respective graphical element within the graphic; generate a persistent association between each assigned XBRL tag and its respective portion of the graphic, wherein the persistent association is visible to a user editing the draft document on the XHTML platform, and wherein the persistent association defines a position of the XBRL tag relative to the assigned portion of the graphic in the subsequently published document; display the persistent association to a user using the HTML platform, and export the draft document comprising the plurality of XBRL tags and the persistent associations to obtain at least one structured document having at least one respective electronically publishable format, the format being one or more of: HTML, xHTML, and PDF. Preferably, the electronically publishable format is one of native HTML, native xHTML, and HTML-based PDF

[0044] The above features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the examples described herein. RWR01-133927PC

[0045] BRIEF DESCRIPTION OF THE DRAWINGS

[0046] The present disclosure will now be described by way of example with reference to the accompanying drawings, in which:

[0047] Figure 1 is a schematic illustrating a known process for preparing and tagging a structured report for filing;

[0048] Figure 2 is a schematic illustrating a content management system and process for preparing and tagging a structured report according to presently described embodiments;

[0049] Figure 3 is a schematic which compares a prior art method of generating and tagging tabular content with a method according to presently disclosed embodiments in which the editing of the tabular content and the introduction of embedded XBRL tags can be performed independently;

[0050] Figure 4a illustrates a graphical user interface for editing tabular content and tagging content side-by-side;

[0051] Figure 4b illustrates an alternative view of the graphical user interface in Figure 4a for editing tabular content and tagging content side-by-side;

[0052] Figure 5 illustrates a graphical user interface for editing content and tagging content side-by-side, which shows how block tags and nested block tags can be applied and displayed to a user;

[0053] Figure 6 is flowchart that illustrates the operations performed by the content management system according to presently-described embodiments;

[0054] Figure 7 shows an example of tagging and displaying graphical content according to presently-disclosed embodiments.

[0055] The accompanying drawings illustrate various examples. The skilled person will appreciate that any illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the drawings merely represent one example of the boundaries. It may be that in some examples one element may be designed as multiple elements or vice versa that multiple elements may be designed as one element.

[0056] DETAILED DESCRIPTION

[0057] As outlined above, the PDF-to-XHTML method creates files which are computationally intensive and wasteful of power and computing resources. More problematically, since many thousands of businesses’ reports will be stored in centralised repositories and made publicly available and since the typical electronic document (produced using known methods) has been produced using a conversion that creates bloated electronic files, a large amount of networking and storage resources are required. At a consumer level, a large amount of bandwidth may be needlessly wasted in downloading and trying to process the reports from the central repository. The result is a widespread waste of power, networking, time and computing resources in general.

[0058] As outlined above, another particular challenge is reviewing and publishing a report. By nature, the report may need to be provided to end users in a number of different formats for different needs, and for different types of devices. A variety of digitally accessible formats are thus a necessity for each report. At each stage of design, RWR01-133927PC editing and review the different formats may need to be revised to fix problems with any one of the publishing formats, which, using known processes, compounds and exacerbates the problems with the review process described above.

[0059] Further, the use of tags such as iXBRL tags requires exacting standards. Most iXBRL tags are manually applied, and tags which fall outside an existing taxonomy (e.g., extension tags) are always manually generated and are manually assigned. The application of all tags also needs to be validated. However, the validation process is typically only possible after the creation of the final document, irrespective of whetherthe document was created using the bolt-on process. Indeed, it may only be possible to validate the accuracy of the tags at the point of submitting a report to the regulator or repository for whom the report is being made. Once again, this creates a long-winded review and revision process that is difficult to avoid and creates a burden both on the personnel creating the report and the computing resources required to generate, process, store and access the reports.

[0060] The present disclosure provides a structured reporting generation system that is able to efficiently integrate all required processes and functions in one platform, in other words, a digital-first solution, and thus avoid the disadvantages of print-first reporting software described above. This is provided by way of a content management system (CMS) that is built to deliver custom-designed XHTML documents and includes additional functionality that known CMSs do not have (e.g., multi-format outputs, advanced table design functionality, integrated XBRL tagging, and online publishing functions including user interactivity and navigation capabilities). These functionalities are described in detail in the following disclosure. In summary, embodiments of the presently disclosed structured reporting generation platform combine some or all of the following functionalities: print / PDF design capability in an XHTML platform; table-editing capabilities of CMS editors; text editing capability of word processors; full navigation functionality the digital design and publishing capability of a web-based publishing CMS; native XBRL tagging capabilities of the underlying content in the XHTML platform, including tables; automated build and design based on a graphical user interface (GUI), to obviate the need for coding (i.e., the user need not be a computer programmer); publishing capability into multiple different output formats from a single source of content in the CMS, e.g.: online browser-based output (HTML / xHTML), PDF, print, RNS Word (RTM), etc.

[0061] Native XHTML editing and reporting

[0062] In more detail, one problem with known web-publishing tools is that they only produce HTML5 code, not XHTML. HTML5 is not suitable for (iXBRL) tagging, which means that no current web publishing platforms are suitable for creating reports which require XBRL tagging.

[0063] Separately, known print-publishing tools typically produce PDF documents. Again, PDF documents are not suitable for tagging and so (as mentioned above) a bolt-on process is typically used in which PDF documents RWR01-133927PC are converted to XHTML which can be tagged. However, this process is error-prone, and causes other technical problems and difficulties. For example, XHTML documents produced in this way are very large (and are sometimes produced from the PDF on a pixel-by-pixel basis) which thus wastes large amounts of storage, and moreover use unnecessarily high levels of computing resources to generate in the first place. Moreover, it is not possible to create a native XHTML report using PDF conversion, because a PDF is a print-based format. The code produced by this conversion is not natively XHTML, and so is of poor quality and in the worst cases produces non-compliant data. For example, the XHTML code from a PDF conversion is liable to contain bugs such as rogue characters and non-matching content order. Furthermore, the tagging of converted xHTML documents is also error-prone, and produces errors such as: lost table structures in tags, misalignment of content in tags, lost table structures in tags, and even lost data and content in tags. Again, these errors, which result from converted XHTML documents, result in non-compliant and non-dig itally accessible data in the XBRL tags.

[0064] At the iXBRL tagging stage, known methods and processes are based on tagging a document created in non- xHTML software, i.e., that is not a publishable or accessible format. For example, iXBRL tags are typically applied to a word-processed document (e.g., in the DOCX format) exported to XHTML, or to a PDF file which has been converted to XHTML. The digital code / data (i.e. the XHTML) is thus produced by software that is not built to create high-quality XHTML suitable for publishing and filing.

[0065] Figure 1 illustrates the type of process 100 that is currently used for preparing and tagging a structured report for filing. The first stage is the document creation and editing stage 102. This creation stage necessarily comprises using multiple different software platforms. Various different software platforms are currently required because financial reports have many different mandatory formats and features, which cannot be implemented with any single piece of software. As illustrated, the collection of software packages typically required includes a word processor (e.g., Word), a design processor (e.g., InDesign), a PDF editor, iXBRL tagging software, a CSV / spreadsheet editor (e.g., Excel), a presentation processor (e.g., Powerpoint), and a disclosure management system. However, once the content for the document has been created in the first stage 102, it cannot yet be filed yet because multiple different output formats are required. Moreover, it cannot be tagged in PDF form. The document must thus be converted to a format that enables iXBRL tagging.

[0066] The conversion and tagging process is typically performed by at least two separate pieces of software, e.g.,: an iXBRL tagging software and a PDF editor. Moreover, because the tagging is overlaid as a separate layer to the converted document, edits to the source document (i.e., using the software for the creation process 102) are not reflected in the tagged iXBRL report produced in 104. Revisions, taking place in drafting process 102, must thus be re-converted and re-tagged in process 104. Furthermore, many other document output formats, e.g., RNS (Regulatory News Service), must be generated by yet a further process involving a different collection of software. The same applies to presentations 108 created from the source document.

[0067] The second stage shown in Figure 1 illustrates the various different report outputs 103 that are generated by the collection of software in the first stage 102. These include: iXBRL report 104, PDF report 105, regulatory RWR01-133927PC release 106 (e.g., regulatory news service, RNS), print report 107, presentation 108, and an online report 109 (e.g., in an HTML format). Each of these individual documents, 104 to 109, are created by separate conversion processes starting from the document created in 102. These documents must then be filed at their respective locations / repositories: the iXBRL report is needed for filing requirements 110, and the other report outputs are required for publishing requirements 111 .

[0068] Figure 1 illustrates the interactions between the multiple different software packages and output reports by the network of lines between stages 102 and 103. This illustrates which software is needed to create each different format in the report output 103 stage, to thereby illustrate the complexity and high user burden that is currently involved in creating structured documents forfinancial reports. For example, no fewerthan five different software packages (word processor, design processor, PDF editor, iXBRL tagging software, and spreadsheet editor) are needed just to create the iXBRL report. As another example, every single report output requires the use of a spreadsheet editor.

[0069] Problems arise because each output report is created individually. Once a document has been created, it cannot be edited in that output format. Crucially, the conversion from document creation stage 102 to report output stage 103 is one-way, and so once the output formats (104 to 109) have been generated they cannot be edited. Thus, in order to prepare revisions, the output document must be discarded and revisions must be made in the editing stage 102 again before re-generating the document. It is also not possible to preview any of the different output formats (104 to 109) prior to generation. Even more problematically, once created, the report outputs are independent of one another, and so cannot be edited collectively. Therefore, if any one document output, say the PDF report, needs to be revised due to formatting errors, every other report output must also be regenerated. As many of the output report formats require multiple different software to revise and re-generate, the burden on a user, and on the computing resources on which the software is deployed, to perform simple revisions and re-generations of output reports is extremely high.

[0070] Due to the conversions necessary, there is no guarantee that digital accessibility, and validity of the underlying content, have been preserved from the source document. Further, due to the different conversion processes, there is no guarantee that the different output formats even contain the same information as each other. It will further be appreciated that this method uses significantly more computer resources, puts a significant cognitive burden on the user(s), and necessitates a significant amount of network traffic is used in editing, sending, and filing the different versions of the reports which (from a processing point of view) have been created independently of one another.

[0071] The above problems result in the current software and processes being too manual (i.e., requiring a significant amount of human input or workarounds), limiting, time-consuming, and moreover expensive to deliver the full suite of formats required. There is therefore a need to provide a digital-first structured reporting tool that meets the following criteria: i. The report can be generated, in the first instance, using a platform and format that enables iXBRL tags to be applied directly. RWR01-133927PC ii. The final structured report should be created natively with XHTML (a version of web HTML which enables, and is used for, iXBRL tagging).

[0072] Hi. The report produced should contain XHTML code / data that is of high quality (e.g., meets digital design, usability, accessibility and data quality requirements of iXBRL regulations and legislation). iv. The aforementioned problems are solved without resorting to manual workarounds, or other manually- implemented processes.

[0073] It should be appreciated that the known method disclosed in Figure 1 , reliant on a PDF conversion, is itself a method that has emerged only recently, e.g., in the past 2-3 years. Prior to this, it was typical to use a Word document as the source for XBRL tagging. Tagging a Word document became wholly unsuitable for document reports that needed to comply with the European Single Electronic Format (ESEF) standard. In order to meet ESEF standards, the PDF conversion method outlined in Figure 1 became widespread. However, as noted above, the PDF conversion method still possesses various inherent technical problems. Moreover, the PDF conversion method involves challenges faced by the users of this method due to the unwieldy and necessarily manual process.

[0074] The challenge in overcoming the aforementioned problems is that there are no tools which are able to perform all the combined tasks, at the level of quality and accessibility required, in a single tool to make the process viable. Embodiments of the present disclosure provide methods and processes which intend to solve this.

[0075] The presently disclosed method enables the generation / creation of electronically-publishable structured documents, wherein generating of the document is performed using the xHTML platform, and allows the direct assignment of iXBRL tags. Specifically, presently disclosed methods provide a content management system (CMS) that is XHTML native, and therefore is purpose-built for XHTML reporting.

[0076] Figure 2 is a schematic illustrating a content management system (CMS), and the method of its use 200, according to presently described embodiments. The CMS 202 itself is a self-contained software platform, in that it delivers native XHTML and has in-built iXBRL tagging capability. Thus, no other software is needed to produce the structured report, although as indicated the CMS advantageously is configured with one or more APIs 204 (application protocol interfaces) that are configured to extract data from external software (e.g., XLS, InDesign (RTM), Workiva (RTM), and the like). The CMS is therefore used to draft the HTML report document 210 of the structured report, which is created and edited in HTML format throughout and within the CMS 202. During the drafting, the CMS enables simultaneous editing, including editing of the tabular content 211 , iXBRL tags 208, text content 212, and graphical / image content (not shown in Figure 2). It should be appreciated that, although the drafting and editing functions (204, 208, 211 , 212) are illustrated in individual boxes in Figure 2, the CMS has ownership of these functions and so all drafting / editing functions are run by - and within - the CMS.

[0077] Since the document itself 210 is native XHTML, the tags can be applied 208 alongside the general editing, rather than as a separate step (as in Figure 1) following the conversion of the document content to a ‘finalised’ form. Once drafted and tagged, the document can be simultaneously published to one or more desired output RWR01-133927PC formats. Unlike in current examples which require the interaction of multiple different software packages to generate each individual output format, as illustrated in Figure 1 , the CMS is configured to generate each of the different output formats (104 to 109) directly from the draft HTML document 201 without the need for any other software. All the same publication formats that must be prepared individually, in known examples as shown in figure 1 , can thus be prepared simultaneously.

[0078] After the relevant formats (104 to 109) have been generated, the finalised documents can be filed and / or published. Unlike the known method shown in Figure 1 , there is no back and forth editing between the finalised publication and the draft document stage, since the iXBRL tags are applied directly to the draft document 210 and not to an entirely separate report output, as in 104 of Figure 1. Furthermore, as indicated in Figure 2, outputting each report format is not a one-way process since revisions and editing can be performed at any time. Previously, (as in the Figure 1 example) a user was forced to interact with multiple software platforms to convert the draft document into a final output format, whereas the present CMS 202 allows a user to generate any given output directly from the HTML document, using the HTML-based CMS platform. Moreover, as illustrated by the links between the document output formats in Figure 2, each output formats are not siloed in the same manner as in Figure 1 , since any revision to the content of the draft document 210 can immediately be propagated to each and every different output format (104 to 109).

[0079] The present method, which enables the generation of a structured report from a single system using ‘native XHTML’ rather than by converting a PDF document to XHTML document, includes various advantages. Since the platform is XHTML-native, the data produced in the first instance is of high quality and enables direct tagging of XBRL because no intermediate conversions have been applied that risk introducing errors or low-quality XHTML code. Since the CMS is XHTML native, it enables reports to be published in formats that are also accessible XHTML online, (e.g., allowing text reflow and the like) and thus significantly increasing the number of users who are able to access the content across, also with the aid of assistive technology. Specifically, this is achieved by increasing the number of electronic devices and browsers able to view the output, providing whatever format the user chooses or is able to access.

[0080] The presently disclosed native XHTML method also significantly reduces the file size of the finalised (i.e., publishable) iXBRL report. This is because the inefficient conversion from PDF to XHTML has been avoided entirely. PDF to XHTML conversion causes very large file sizes due to the fact that the precise content positioning in the PDF is encoded at the pixel-level. The inefficiencies of storage and processing caused by the excessively large files (e.g., in excess of 70 MB) are then magnified by the large volume (e.g., thousands) of mandatory reports, which creates a significant drain on resources for data storage, dissemination, and processing at all stages of a report’s lifecycle and use.

[0081] Another advantage of the presently disclosed native-XHTML platform is that the iXBRL tagging process is more straightforward and thus less error-prone. This is because the user is able to place tags directly onto ‘live’ digital content. By contrast, in known methods, users are forced to add tags as an independent ‘layer’ (as would be the case when tagging a converted PDF document) which introduces a disconnect between the tag layer and RWR01-133927PC the underlying content layer. In presently disclosed methods, however, the tags are applied in the same XHTML format and using the same platform as the underlying content. Thus, tags are intrinsically linked to the underlying content in a persistent way, which affords more convenience when editing and revising reports. In other words, a persistent association exists between each assigned XBRL tag and its respective content portion due to the fact that both the underlying content and the tags are generated using the same platform, and using code that may be interpreted by the native XHML editor. The persistent association moreover facilitates cross-referencing of different portions of the structured report, i.e., by keeping track of associated portions of the document. An advantage of this is that cited portions of the document are automatically and correctly updated following editing (typically, updating of internal document references is necessarily manual because of the design and editing workflow).

[0082] In more detail, in known reporting methods and platforms, the ‘layer’ of tags is applied post-conversion to HTML, meaning that the layer of tags is in effect a separate entity to the underlying content. This means that PDF proofing revisions to the underlying content are not reflected in the tag placement on the PDF tag layer, and so tags must typically be manually re-positioned to reflect changes in the underlying content. Advantageously, the position of tags applied using presently disclosed methods automatically responds to edits to the underlying content, since a persistent association exists between each assigned XBRL tag and its respective content portion. Thus, the persistent association defines a position of the XBRL tag relative to the assigned content portion in the subsequently published document, meaning that, once applied, the tag persists in the correct content position and will not need to be re-applied. In summary, this eliminates the re-conversion and re-tagging process when creating multiple proof iterations of a report. By contrast, PDF-to-XHTML conversion cannot deliver large-volume tagging at speed because the PDF conversion and tagging process is manual. When there are large volumes of tags, this process is very slow and would significantly delay report publication and filing to regulators. Thus, the presently-disclosed CMS provides a solution to a crucial goal of the new mandatory tagged format, which is to speed up disclosure and publication, not delay it.

[0083] Moreover, in a native XHTML editor as provided by the presently disclosed methods, the XBRL validation checks can be continually, or periodically, performed on XBRL tags throughout editing. This is because the XHTML editor has efficient / d i rect access to the underlying content, and can determine the persistent association between tags and underlying content, and is therefore able to assess the nature (or value, if the content is a number) of the underlying content in order to determine whether the tag and its content is appropriate or inappropriate. This enables errors to be fixed during the editing process. By contrast, in known methods, errors in XBRL tagging are typically only revealed at the end of the editing process (possibly only after submitting to a central repository), as the validation is typically performed by a separate platform. As a result of current methods, many errors and problems are seen in publicly filed reports and these cannot be fixed - once filed, the reports with errors remain public for 10 years.

[0084] Furthermore, structured reporting tools that are XHTML-native enable XBRL tagging that is more widely accessible and compliant. For example, the present native XHTML platform provides assistive compatibility, reliable user-controlled functions such as text searching (i.e., in the published report, such as in a browser RWR01-133927PC environment), and text enlargement (e.g., the text can be automatically re-formatted dependent on the type of device or display output, such as a mobile device, so that the report is readable / accessible on a wider range of electronic device). More specifically, the present XHTML platform enables text reflow in published reports, where text reflow refers to the ability to reorganise or rearrange blocks of text depending on the area of the document being captured by the electronic output display. For example, elements of the text should reflow to fit a user’s browser, e.g., rearranging a two-column text into a single column that is the width of the document pane. By contrast, PDF-to-XHTML conversion cannot be accessibility compliant; this is because XHTML code must be written and built natively in order to comply with all accessibility requirements, e.g., text reflow. Text reflow is expected in web accessibility, but it is not obtainable using PDF conversion because the format (i.e., XHTML converted from PDF) fixes the position of all elements on the page due to the pixel-level conversion, so the content cannot reflow.

[0085] Another general advantage afforded by the present native XHTML platform is that it permits interactive iXBRL reporting, e.g., including dynamic graphs, web-based navigation of the report (e.g., text search), hyperlinking, embedded images and video, and the like. Known methods of producing structured reports do not provide any level of interactive content, since known methods typically create / write the report in a non-HTML-based format.

[0086] Providing a single native-XHTML platform makes the generation process much more efficient overall, makes the quality of output more compliant and more efficient to handle via electronic devices, and makes all publishing requirements achievable at a lower cost than creating like-for-like outputs using current, manual, process (indeed, the full accessibility and usability capabilities mentioned above cannot be achieved using current methods and software across all the output formats).

[0087] Integrated Digital Publication with Multiple Output Formats

[0088] Another problem with current print-based and web-based reporting production tools is that they cannot simultaneously produce the multiple required formats in reporting, i.e., PDF, online, filing, and print, from the same initially produced content. Consequently, in known production methods, computing resources are wasted using a plurality of different programs in order to manually convert or copy / paste the report content into the plurality of software for the many required outputs. Moreover, known software platforms necessarily require a large amount of manual input and oversight, which puts an unnecessary cognitive and resource burden on the user, and moreover creates yet another avenue for errors to be introduced. As a result, known publishing methods are only able to achieve basic digital publishing, i.e., with subpar or non-existent compliance and technical accessibility, due to the lack of flexibility that is inherent in the combination of multiple different platforms. In summary, there is no known method, let alone one single platform, that is able to generate all the required formats to the required standards of accessibility, simultaneously, and with full compliance.

[0089] The presently disclosed structured reporting generation platform advantageously provides fully integrated functionality that enables the digitisation of structured reports in a fully accessible and compliant manner, significantly reduces the cognitive burden of users and error rate. Moreover, the presently disclosed methods RWR01-133927PC make efficient use of available computer resources by virtue of the fact that only one platform is needed to produce the various outputs, and further by virtue of the fact that the speed and efficiency of publishing is significantly enhanced.

[0090] The presently disclosed platform is a single content management system (CMS) for multi-format reporting, which obviates the need for inefficient manual and resource-intensive (not to mention slow and expensive) processes that are currently necessitated (e.g., as indicated in Figure 1) by known software.

[0091] Advantageously, the present CMS delivers XBRL tagging which is native to the CMS (rather than an add-on of a different program, or incorporated using a different program entirely). Since the presently disclosed CMS has integrated iXBRL functionality and uses the XHTML format, it enables straightforward web-based editing, in contrast to the print-based software environment of known solutions.

[0092] Moreover, the use of a CMS enables simultaneous publication to any one or more of the possible output formats described above (e.g., formats include online iXBRL report, iXBRL filing version, PDF, print) from the single source of xHTML content. Advantageously, in the presently disclosed multi-format publishing CMS, all output formats are generated from the same system, and from the same source of content. This enables much more efficiency and accuracy for editing (and design and sign-off etc), and moreover provides greater consistency and reliability in the resultant output compared to methods that rely on manual copy / pasting across multiple software platforms.

[0093] Multi-format CMS also solves the technical data rendering problems of PDF conversion to HTML. Accurate data disclosure is a vital part of reporting to regulators, investors and the public which is currently causing significant data non-compliance, and storage and usability issues across thousands of large European Single Electronic Format (ESEF) filings.

[0094] The automation of editing processes provided by the presently disclosed CMS make processes faster, more efficient (i.e., less computer-resource intensive) and more reliable. For example, in the automated PDF and print outputs that may be generated by the presently disclosed CMS, all page referencing tasks (which, typically, are manual) are automated. This is enabled because all page numbers can be cross-referenced dynamically from the digital hyperlinks contained in the native XHTML source code. This provides a significant advantage over the currently known print-first PDF process, which takes up enormous time and computer resources, and has a high risk of human errors. Further, the CMS is able to produce digitally compliant XBRL tags in the first instance, which a converted PDF cannot, since the XBRL tags are applied using native XBRL software which is not erroneously transformed by any bolt-on conversion processes.

[0095] Currently, there is no way to generate a document and publish it to multiple formats without very complex and heavily templated systems. Currently, templated design systems have no XBRL tagging capability and no design flexibility. For example, to publish a newspaper in each of i) online, ii) PDF and iii) print version formats, requires a pre-designed templated system, which cannot publish any other design to multiple formats. Typically, RWR01-133927PC known solutions are able to produce document-format outputs only (e.g., PDF, or DOCX formats), and are unable to publish an accessible online format, e.g., that behave like a website, e.g., an HTML or XHTML format.

[0096] The solution provided by the present CMS platform offers non-templated (i.e., uniquely configurable) content to be simultaneous output to multiple formats. Consequently, the presently disclosed platform provides multiformat functions integrated into a single digital-first (i.e., XHTML-native) design and publishing system (i.e., web CMS, XHTML, XBRL tagging, and simultaneous multi-format outputs). The present CMS platform is therefore configured to export a structured document having at least one respective electronically publishable format, wherein said format being one or more of: HTML, xHTML, and PDF. Because the present CMS is native to HTML, the output format is preferably one or more of native HTML, native xHTML, and HTML-based PDF. In more detail, embodiments of the CMS platform that provide this solution may include at least some of the following functionalities, which may be implemented as part of the CMS.

[0097] I. InDesign (RTM) content sync with the CMS to sync complex reporting content in both directions.

[0098] Advantageously, the presently-disclosed CMS is able to interface with the InDesign (RTM) software (and other external software) to import content from InDesign into the native-XHTML platform of the CMS. Ability to interface 204, via use of APIs, is indicated in Figure 2.

[0099] II. Advanced CMS-based table functionality.

[0100] The presently-disclosed CMS provides various complex design features that are not available in known web publishing software. These design features facilitate the user-machine interaction in terms of generating complex content from multiple sources, and additionally help to mitigate the ubiquitous data rendering problems that typically arise from known PDF conversion processes: a) Since the present CMS is native to xHTML, CMS-based tables have inherent responsive accessibility- compliant behaviour which automatically adapts the format of tables, e.g., large / wide tables, to display in an accessible format across all types of devices and browsers. b) Tables that can be generated in the presently disclosed CMS have comprehensive design settings for designing every element of a table, e.g., cell styles, paragraph text styles in cells, hyperlinks in cells, super / sub- scripts in cells, spacing, colour, background, keylines, fonts, column width, table header and the like. This level of design control is not available in known web-based and digital XBRL software. c) Table templates can be pre-designed in the present CMS, i.e., the format, structure, information type, etc can be pre-designed as an empty template prior to including the data itself. Advanced editing and paste functions allowing a user, subsequently to constructing the table template, to paste tabular content from any external source into the CMS-based table. Once pasted into the pre-constructed template, the table retains both its format and any pre-included tags in the table design that have been pre-constructed in the CMS. In this way, RWR01-133927PC advantageously, table structure and table data can be constructed independently of one another, and indeed in parallel / simultaneously. d) Fully integrated XBRL tagging in tables, which no current web CMS software (like WordPress, AEM, Umbraco, SquareSpace, Wix, Drupal, etc) can do.

[0101] III. Embedded XBRL tagging capability into CMS content

[0102] It is particularly advantageous to be able to embed XBRL tagging information with the content, i.e., as provided by the presently disclosed CMS. Embedding tagging data enables greater content automation thus significantly reducing the cognitive burden on a user, improves accuracy, and audit trails. In particular, a major advantage over PDF-based report tagging (which stores the tagging data as a separate layer overlying the content) is that content may be synchronised automatically from other (e.g., external) systems into the present CMS, and the user will not need to modify the placement of their tagging, or the style of the content, within the CMS.

[0103] Specifically, embedding XBRL tagging data allows for table content stored externally to be synchronised automatically with pre-formatted tables, as mentioned above. This automatically pulls data in table software, which may be undesigned, (e.g., Excel, Workiva etc) directly into the tables designed using the present CMS which can be pre-populated with XBRL tags. It is possible to pre-tag a template of a table, or the cells therein, prior to populating the table with content / values because the type of data or values may be known beforehand when designing the table. This significantly improves human-machine interaction by automating the highly manual copy / paste of huge volumes of tables that is typically required in reporting.

[0104] Furthermore, the pre-defined table format and tagging settings remain fixed, as defined by the user of the CMS. It is also noted that these design settings can be graphically implemented, e.g., by means of one or more graphical user interfaces, such that no programming expertise is required of the user. The table and tagging design settings thus remain unchanged as content gets automatically populated into the tables, and moreover as the content gets repeatedly updated during proofing. This hugely improves the accuracy of both the content and the tagging data, as both can be individually edited and set, i.e., the insertion and editing of the tags are not dependent on the existence of, or updates applied to, the underlying content.

[0105] For example, the presently-disclosed CMS is able to automatically synchronise a cell, or a plurality of cells, based on external tabular data, e.g., any table-based platform such as Excel, directly into the pre-constructed and / or pre-tagged template (which acts as a ‘content placeholder’) in the CMS. For example, the preconstructed template may be a data table or text frame placed into an HTML block in the CMS. This means that a large number (e.g., thousands) of content and data elements can be managed and edited externally (e.g., in widely used and widely accessible table-based data systems) and synchronised into the present CMS (e.g., Excel-based financial and data consolidation systems such as Oracle Hyperion (RTM), OneStream (RTM), RWR01-133927PC

[0106] Tagetik (RTM), Workiva (RTM)) and dynamically and automatically updated in the pre-constructed and XBRL- tagged placeholders.

[0107] This separation of: i) the content editing, and ii) the table design and tagging offers, technical advantages and improved accuracy over PDF-based systems. This is because, in PDF-based reporting platforms, the content must be manually copied / pasted from the source data system into a PDF publishing tool (e.g., InDesign (RTM)) where the PDF is created, and then subsequently converted for manual tagging. In the present CMS, the content can be directly extracted from the external source, thus eliminating the risks of copy / paste errors across thousands of content modifications throughout a project. Moreover, this capability, which is a result of the embedded XBRL tags and content, means that all XBRL tagging and tabular design that is pre-defined in the CMS remains persistently linked the underlying content no matter how many times the underlying content is updated over the many months of report drafting.

[0108] Figures 3a and 3b illustrate how the presently disclosed embedded XBRL tagging improves the process of generating content (in particular, tabulated content) compared to prior art methods. An overview of prior art methods 300 that use PDF conversion publication is shown in Figure 3a. In known methods, the tabular content is generated using at source, e.g., using financial and data consolidation platforms. The format of the table, and the table’s contents, are created on the same platform in tandem. Once the table has been completed, it is sent (often manually by copy and pasting) to a publishing platform tool (such as InDesign (RTM)). The publication tool collates all written and tabular content that is used to form the report. The report, including the completed tables, is published to PDF. As indicated in step 104 of Figure 1 , the tagging is applied subsequently to the generated report. Thus, any edits to the contents of the table require re-starting the editing using the content generation platform. The revised document must then be re-published (by re-converting the updated report into a new PDF), at which point the tag layer will need to be manually re-applied.

[0109] By contrast, Figure 3b shows how the presently disclosed CMS 202 compartmentalises the editing of the tabular content from the formatting and tagging of the table. Within the CMS 202, the format and / or design of a table placeholder 307 may be defined 306. Tags (not shown) can also be pre-applied 308 to the table, even before the underlying content exists. Separately and independently from the CMS 202, the content (e.g., data values) for the table can be produced in an external platform 304, such as CSV-based platform. The data may be unstructured or undesigned in the external platform. The CMS is configured to automatically extract the relevant data from the external platform into pre-formed table to obtain a completed table 309. Advantageously, further edits 314 can continue to be made on the external platform side, and the CMS can refresh the table to extract updated table contents. Advantageously, the format of the table and tags applied to the table only need to be generated once, and remain unchanged despite the fact that the underlying content can be subject to change. This has the further advantage of allowing different sets of users to be in control of the table design (in the CMS) and the underlying data values (obtained from the external platform). Data can be extracted from the external platform 304 via the use of APIs, for example.

[0110] IV. XHTML-based outputs from the CMS. RWR01-133927PC

[0111] By contrast, known methods, including known web-based CMSs, typically only produce HTML5 output, which is not compatible with XBRL tags. Furthermore, web-based CMSs also do not produce a high quality, easily designed and publishable PDF version of the digital content.

[0112] V. All formats (online, PDF, filing, print) may be output from a single system, based on a single source of content for all channels of publishing and filing.

[0113] As described above, and illustrated in figure 2, advantageously, the presently disclosed platform provides multi-format functions integrated into a single XHTML-native CMS that enables the simultaneous publishing of various formats including an interactive (i.e., browser-based) report with iXBRL viewer, PDF for download, iXBRL filing report, Word(RTM)-ready format for RNS (Regulatory News Service), presentation formats, and ‘print-ready’ PDF format.

[0114] VI. Fully customisable design, layout and style sheet functionality across formats.

[0115] Advantageously, the presently-disclosed CMS is not template-based and so provides flexible design and fully configurable outputs, without requiring the user to have programming experience or to provide any coding input. Thus, the design of the content is controllable by a user at the content and page level, obviating the need for fixed template designs with all their inherent design limitations.

[0116] VII. Instant and simultaneous build of all outputs can be automated at sign-off.

[0117] This has the advantage that no post-production XBRL tagging is required by a different platform, since the tags, and the persistent association between the tags and the underlying content to which the tags are applied, are part of the content itself, all having been generated using the native XHTML format. The tags, encoded with XHTML, can be readily transformed into any of the desired output formats such that the substance contained within the tags, and the positioning of the tags relative to the underlying content is preserved in the final output.

[0118] VIII. Integrated roll forward and project duplication.

[0119] In prior art methods, typically previous years’ reports cannot easily be exploited to speed-up the creation of new reports. Thus, new reports have to be generated from scratch, which is necessary because the formatting of the report (including formatting of tables contained within) is inextricably linked to the content itself. Also, the XBRL tag layer is dependent on the format of the underlying content, and so tags need to be entirely re-applied to new content created for new reports.

[0120] The present CMS is configured with integrated roll forward capability, which has many technical, accuracy, and process advantages over current PDF-based tagging software. The integrated roll-forward process RWR01-133927PC automatically provides an updated version of the content and the tagging of a former report, ready for the new project to begin. This is possible because the entities of i) XBRL tags, ii) underlying content (e.g., text and / or numerical data), and iii) report formatting, are effectively separate entities that may be defined by separate (but linked) portions of the xHTML code of the CMS. Yet, these entities are persistently linked so that the position and formatting of one entity is updated automatically in dependence on the position and formatting of another entity.

[0121] In one specific example, the roll forward capability of the CMS provides an automated update from the old taxonomy used for tagging, to the latest tagging taxonomy, e.g., as required for the current year’s reporting standards. For example, an Authority may update tagging / accounting taxonomy and standards every year. An advantage of having the roll forward in an integrated CMS, as presently disclosed, is the newer updated taxonomy can be used to automatically replace the prior year’s taxonomies across all the XBRL tags. This is especially advantageous because the updating of tagging taxonomy can be performed without having to retag the content. Thus, the same tags from a previous year’s report can be rolled forward to use as a template for a subsequent year’s report, but with an updated taxonomy.

[0122] Moreover, because the content itself in the present integrated CMS is also rolled forward it means the accuracy of the content and tagging combined is significantly improved from the outset, i.e., before the new content drafting begins. This means that the rolled-forward reporting starts from a significantly more consistent and solid base than in current PDF / print-based processes and tagging set-ups. Thus, the integrated CMS provides for a significantly improved human-machine interaction, since a significant amount of data and information can be reused for generating a new report in an intuitive manner, where that reuse is provided by virtue of i) the fact that everything is encoded using common xHTML language in the same CMS ii) the compartmentalisation of XBRL tagging data, underlying content, and report formatting iii) the persistent link between all compartmentalised entities.

[0123] In known methods, manually rolled-forward set-ups are slow, taking at least 1-2 weeks to roll forward. They are also inaccurate and not readily useable as a basis to add new content, partly because the rolled-forwards tags in PDF conversions are manually re-applied as a separate tagging layer (i.e., not integrated into the HTML content). In contrast, the present MCS CMS tags are automatically and instantly pre-embedded with the content even when it is updated with the new text and data, which is both faster and more accurate. Finally, the present roll-forward capability automates the date data on every tag automatically, which is a manual process in current PDF-based tagging software.

[0124] IX. Import structured table data and structured XBRL data from other sources

[0125] For example, the present CMS platform allows content and data to be extracted from other formats such as XLS, InDesign and Workiva. RWR01-133927PC

[0126] In summary, the above functionalities incorporated into the presently disclosed CMS provide for at least the advantage of enabling the generation of reports having higher quality data (i.e., such that reports can be analysed and compared by automated means using the expected standards of structured reports, rather than resorting to manual comparison and analysis methods).

[0127] X. Higher quality, more efficient data when exported to XHTML

[0128] The presently disclosed CMS also provides the advantage that the XBRL reading order of the original XHTML document matches the order (and position) in all of possible publication formats, and moreover provides faster XBRL processing since the XBRL tags are applied using a single native-XHTML platform. Furthermore, as mentioned above, the outputs produced, including PDFs exported from the XHTML source file, are significantly smaller in size since all content of the structured report is built using a native XHTML platform, and has not been converted at the pixel-by-pixel level.

[0129] Integrated XBRL tagging

[0130] Known software and methods for applying XBRL tags are based around tagging XHTML data that has been created from a document (e.g., a DOCX or Word document) or conversion processes (e.g., from a PDF conversion). The conversion is performed by a further software or process. Thus, the original source document for obtaining the XHTML is separate from the tagging software. Consequently, in known processes, the process of tagging is separated from the creation of the XHTML document / report, and in typical examples, three separate processes are used: original document generation, conversion to XHTML, and XBRL tagging.

[0131] When sources of XHTML data are not ‘native’ to the XHTML code (e.g., the source document was generated in a word processor or from a PDF), the resulting XHTML data and content quality is poor. For example, the XHTML code produced from a PDF conversion is liable to contain bugs such as rogue characters and nonmatching content order. One cause of this is the fact that the encoding of the PDF to XHTML happens at the pixel level. Consequently, the XHTML code is not compliant with digital and accessible requirements. When XHTML is not compliant, the XBRL-tagged data is also not compliant. This presents a technical difficulty in correctly and efficiently applying XBRL tags; indeed, known processes often require manual input and many workarounds.

[0132] In more detail, in known PDF conversion methods, tagging always follows subsequent to the editing of a document, and the tagging is applied as an independent layer to the document, i.e., ‘overlaid’ over content. So, when one portion of text content changes every tag must be manually moved (i.e., re-applied to the correct portion of content) as well. This is slow, inefficient and highly error-prone. However, in the native XHTML CMS of the present disclosure, the tagging is embedded (i.e., persistently associated) with the text content, such that the iXBRL tag is persistently assigned to that portion of text in both the draft and published document. When the text is edited in the CMS, the position of the tag moves with the edited text. RWR01-133927PC

[0133] Another problem with known tagging methods arises from the scale of the documents, and the degree of collaboration required. For example, a typical report may contain around 500 pages or more, and may be created by up to 100 different contributors. During the proofing process there may be many thousands of content edits to be made. A structured report may have up to 10,000 XBRL tags applied to the content, and so it will be appreciated that manually moving XBRL tags as the content is edited is not viable. It is therefore prohibitive to perform tagging alongside the editing and document creation. In order to avoid the prohibitive burden that would be placed on users to continually manually edit the position / content of the XBRL tags, in known methods, PDF conversion and subsequent tagging is typically left to the final stages. This, however, increases the risks of tagging errors, and moreover the XBRL tags may still need to be manually re-applied since they are merely ‘overlaid’ as a separate layer in a transient way, where the XBRL layer is not linked to the underlying content.

[0134] Advantageously, in the presently disclosed native XHTML CMS platform, tagging can be performed alongside editing. CMS editing with integrated tagging on native XHTML requires no manual positioning of tags. The tags move with the content as it is edited, as a result of the persistent association between tags and the underlying content to which they are applied. This means that it is significantly more efficient, and less error-prone. Thus, tagging only needs to be performed once, obviating the need to re-do tags in each proofing round, and significantly reducing, if not removing altogether, the cognitive burden that would otherwise have been placed on users who apply the tags. Generally, because the present CMS is a web-based publishing CMS, with fully integrated iXBRL tagging functionality, (i.e., not bolted in or applied in a separate XBRL software), the present platform advantageously facilitates the human-machine interaction needed to produce a structured report in a way that is not possible using known methods.

[0135] Figures 4a and 4b illustrate an example of a user-interface provided by the presently-disclosed CMS for populating, and previewing, XBRL tags into tabular content. In particular, Figures 4a and 4b show the persistent relationship between XBRL tags and cells or blocks of cells. Figures 4a and 4b also illustrate how the interface conveys the position of applied tags to users, and displays a preview of the properties and / or the fact-value of applied tags.

[0136] Figure 4a shows a graphical user interface comprising an XHTML table editor 400 on the left-hand side, and an integrated tagger interface 402 on the right-hand side. The table editor 400 comprises various fields (404, 406, 408, 410, 412) that show information comprising, in this example, the name of the table, the position of the highlighted cell and the like. The table editor 400 displays a table 414 of data, which in this example comprises financial reporting data. The table editor allows the numerical data in the table to be created and / or updated. The editor also comprises functionality to allow CSV / Excel data stored externally to be imported.

[0137] The integrated tagger interface 402 has two tabs, the first “tags” tab 416 shows the tab selector, and the second “Tag data” tab shows more detailed tag data and information for a selected tag. Figure 4a shows the previews available when the “tags” tab 416 is selected. The tag role 420 field displays the name / type of tag. The larger field 422 at the bottom of the tagger interface, labelled “applied tags”, shows a description of the tag (or tags) applied to the cell selected in table 414 of the XHTML editor 400. The tagging interface also enables additional RWR01-133927PC tags to be applied to any selected cell. This can be done irrespective of whether a source value has been input into the cell, i.e., since the persistent association between the tag is applied to the cell that contains the source value rather than the source value itself.

[0138] In the example shown in Figure 4a, cell C4 is selected in the XHTML editor 400 (indicated by the shading shown in cell C4). The properties of the tag that has been applied to cell C4 are shown in the tagger interface 402. In this case, the name of the tag is shown in field 422. It should be appreciated that the tagging interface 402 can show all appropriate properties of the tag, e.g., its context, fact-value, concept, and the like.

[0139] Figure 4b shows the information displayed when the “tag data” tab 418 is selected. In this example, the selected cell is again C4. The detailed fields shown here include the “period” 424, which may show the accounting dates relevant to the financial report, and a “numerical value information” 425 which may contain information such as the accuracy, scale, and XBRL sign of the value within the tagged cell. Fields 426, 428, and 430 show the value data for the cell selected, e.g., the unit 426 (in this case GBP), the source value 428 (in this case 10,000), and the fact-value (in this case 10). The “cell” properties” field may include all other detailed information associated with the properties or concept of the tag. Examples include: ID, data type, period type, balance, standard label, documentation label, and total label.

[0140] It should therefore be appreciated how the advanced CMS-based table functionality, described in detail above, can be implemented / facilitated using the graphical interface shown in Figures 4a and 4b. It should also be appreciated how the XBRL tagging capability is fully integrated with the table editing interface. Specifically, all table editing actions can be performed simultaneously with tagging-editing actions, and both the table and the applied tags may be revised / edited indefinitely even after finalising the document. It should also be appreciated that advanced functionalities such as integrated roll forward are facilitated by this interface, e.g., since the corpus of tagging data is inherently (and persistently) linked with the tabular structure, meaning that the same corpus of tagging data can be reused for future reports simply by importing new source values.

[0141] Figure 5 shows an example of a graphical user interface, which illustrates how the XBRL tagging is integrated with the content editor for a structured document. In particular, Figure 5 shows how tags applied to blocks of text, and nested block tags, can be displayed and edited by a user. Tags may be applied to individual words or line items (not shown) within the content that is displayed on the content editor 500. Figure 5 specifically shows how block tags can be applied and displayed. As described in more detail elsewhere, text block tagging involves applying one or more XBRL tags to ‘blocks’ of content, where that content may contain multiple information items. The left-hand side shows the content editor 500 and the right-hand side 502 shows the integrated tagger interface 502.

[0142] As illustrated in Figure 5, a large section of content 504 (which may contain text) falling under a general heading has a first block tag applied to it. The block 504 in Figure 5 serves to indicate that all the content within the box is to be persistently associated with the block tag. Within this larger block 504, two ‘nested’ block tags 506, 508 have been applied, where each nested tag relates to a sub-heading within the parent block tag 504. The RWR01-133927PC formatting of the block tags in the CMS content editor 500 graphically indicates the hierarchy of the tags to the user, i.e., the parent block tag 504 is wrapped around both of the nested tags 506, 508.

[0143] Each of these block tags is individually selectable 504, 506 ,508, and Figure 5 shows that the block tag 506 corresponding to “sub-heading #1 ” has been selected. The right-hand tagging interface shows the “Tags” tab 510 (selected in figure 5) and the “Tag data” tag 512, whose functionality is as described in respect of Figures 4a and 4b. The tag role 514 field displays the name / type of tag, and the larger field 516 at the bottom of the interface 502 (labelled “applied tags”) shows a description of the block tag that has been selected in the editor 400.

[0144] Advantageously, and uniquely in a native HTML CMS editor, the XBRL tags are integrated with the content and move with the underlying text / content as it is edited. This means that the hierarchy of nested tags, and the relative position of adjacent block tags, moves automatically with the text when it is edited. In a similar manner, the size of the block tags will expand and contract as needed to accommodate the content that is contained within it.

[0145] Figure 6 is a logical flowchart that illustrates the operations performed by the CMS (and the user interacting with the CMS) in generating a structured report from start to finish. All of the operations shown in Figure 6 happen within the confines of the CMS platform (e.g., as indicated by the CMS 202 in Figure 2).

[0146] The starting point is generating content, using an XHTML platform, for the draft report. Content can include text, tables, and indeed other bespoke items enabled by the CMS (such as images, charts, drawings, videos, animations, and the like). Additional relevant content such as text and tables may be extracted 612 from existing documents using in-built APIs. Advantageously, the extracted content is exported as high-quality XHTML code, and so remains compliant and digitally accessible, unlike the current methods of PDF-to-HTML conversion which are of poor quality because they (necessarily) attempt to convert all information of the document (including positional information, etc.) rather than the core relevant content.

[0147] At step 602, iXBRL tags are assigned. This can be in the conventional sense, i.e., to line-items, or can be applied to larger portions of text content, graphics, tables or cells within tables. As indicated, the presently disclosed CMS also enables text block tagging (which, as indicated in 614, can be done retrospectively). Furthermore, nested tags can be applied to smaller subsets of content within a superset of content to which one or more tags have already been applied. Persistent associations are generated 602 for all types of (as between the tag and the portion of content to which the tag is applied). Figures 4a, 4b, and 5 illustrate how the CMS can enable a user to graphically apply tags to the desired portion of content.

[0148] The separate feature of text block tagging, advantageously provided by the present native XHTML CMS, is that it enables ‘text block tagging’ to be applied in a much more efficient manner. Text block tagging is the method of applying one or more XBRL tags to ‘blocks’ of text or other content, that may contain multiple information items. This is in contrast to simply tagging each piece of information one by one, which typically involves RWR01-133927PC applying individual tags to portions of line-item data within structured reports (e.g., to line-item data of financial statements). Text blocking therefore enables multiple tags to be simultaneously applied to a ‘block’ (which may be a line, paragraph, or page etc) of content.

[0149] In PDF conversion tagging methods, tagged text block content is of poor quality (i.e., is not digitally accessible, and as such is often not compliant with regulations) when applied to XHTML documents converted from PDF. In the PDF conversion method, table structures are lost, rogue characters appear, content reading order does not match the content itself and, in some examples, content disappears completely. Moreover, persistent associations between tags and content are not typically generated. This is because the structure and quality of the XHTML code in a PDF conversion is so poor. For example, if multiple stakeholders are involved, it is not technically viable for multiple users to apply multiple tags to one block. In the present methods, more than one user can simultaneously apply tags, and one user is able to apply a nested tag within a tag already applied by another user. Further, typically, separate software is required to overlay tags on the final report, which is wasteful of computing resources. In the present method, the tags can be applied as the document is edited (602, 604). Further, In the method enabled by the presently disclosed CMS, which creates native XHTML, text blocks inherently do not contain any of the bugs and unwanted characters that may be created by PDF conversion to XHTML. In other words, native XHTML from the presently disclosed CMS is ‘clean’ which means it delivers higher quality, fully compliant content and data inside the tag when it is applied to the XHTML.

[0150] In known PDF conversion tagging (as outlined in Figure 1), nesting is applied via multiple tag layers that are not linked with the content of the document, or indeed each other. As outlined above, this makes the process of applying tags more complex, time-consuming, and increases the risk of errors. In addition, when reviewing the nested tags in a PDF-converted report, these nested tags are harder to see and check as it is not easy (or possible) to determine the intended association between the one or more separate layers and the underlying content. By contrast, when nested tags are applied 616 to native XHTML in a CMS with integrated XBRL tagging, as in the presently disclosed platform, these nested tags move with the content. Moreover, the intended association (which is a real, persistent, association that exists in the XHTML code) can be viewed such that the connection between the tags and the content can be verified.

[0151] Step 604 indicates that the user edits the content by removal, addition, or alteration, subsequent to applying at least one tag. The part of the content edited can be a portion of the document that has not been tagged or can equally be a portion to which a tag has been assigned. Step 604 is thus user-initiated.

[0152] Step 606, however, is an automatic functionality of the CMS platform that operates based on the persistent association. Specifically, the assigned tags respond to the editing 604 by moving with the portion of content to which they have been applied, such that the relative positioning between the tags and their assigned content is preserved. In other words, since the part of XHTML code edited is in principle independent from the part of XHTML code that defines the persistent association, the editing process has no effect on the existence or assignment of the tag. Thus, in contrast to PDF conversion creation methods, revisions to the content do not necessitate re-application of tags, since then tags are not ‘overlaid’ as a separate entity. Thus, advantageously, RWR01-133927PC tagging can be done in tandem with editing and one does not have a detrimental effect on the other. Moreover, more than one person may edit the same document, and cause the loop of 600, 602, 604, and 606, to iterate, for the same reason above, i.e., because of the known associations between the XHTML code representing the tags and their persistent association and the XHTML code representing the rest of the underlying content. This, in effect, solves another problem of version control, since one editor’s edits retain the tags or edits previously applied by another editor.

[0153] Once the document has been finalised to the desired standard 608, the document can be simultaneously output (and filed) to any of the one or more desired formats. This provides the technical advantage that only one source document is needed to produce a final report, in contrast to current PDF conversion methods which, as indicated in Figure 1 , may require two, three, or even more separate software processes (104, 106, 108) to the source document before the document can be finalised. In contrast, the present CMS enables the final conversion to the desired output to be performed immediately upon finalization (e.g., sign-off) of the report.

[0154] In more detail, the nesting 616 of tags provided by the present CMS can be reviewed more easily and more reliably in the present platform, as illustrated in Figure 5. For completeness, ‘nesting’ is where inner tags are assigned to portions of texts, or tables, within an existing tag that is applied to a superset of the text or table. When tags are nested, an association is created not only between the sub-tag and the portion of the document but also between the sub-tag (e.g., tag 506 or 508) and its ‘parent’ tag (e.g., tag 504). Furthermore, the nesting is performed in such a way that the nesting is displayed in the CMS’s HTML editor 500, e.g., as shown in Figure 5. Nesting is different from multiple tagging, wherein a plurality of tags are applied to the identical block of text (though further tags may also be ‘nested’ within the tagged block).

[0155] Moreover, the present CMS is XHTML based, which means that multiple stakeholders can access the document (which may be stored at a shared server, or on the cloud, for example) for editing. Further, by virtue of the fact the assignment and position of existing XBRL tags is preserved following edits (indicated in 606 of Figure 6), version control is automatically handled by the XHTML platform, thus significantly easing the machine-human interaction that would otherwise be required to deal with loss of XBRL tags. Moreover, this process significantly reduces network traffic and local storage, which would otherwise be required is excess for editing a ‘final report’ which must be shared amongst the multiple stakeholders for local editing (in order to mitigate version control divergences).

[0156] Furthermore, as mentioned above, tags (including block text tags) are typically applied to the final report. Thus, in examples where the final report is subject to edits after the tags have been overlaid, they must be re-applied since the association of the tag(s) to the block of content (and association with the sub-set of content to which nested tags may have been applied) is lost in the editing process, or did not exist in the first place.

[0157] In addition to the above, the present CMS also provides to ability to perform on-the-fly validation of a tag, e.g., to determine an incorrectly applied tag, or a tag relating to the same fact but applied to different values. The present platform is able to automatically raise an error flag (e.g., displayed in a graphical interface, herein called RWR01-133927PC a validation console, visible to the user) that facilitates user correction of the tag and / or the underlying entry. Furthermore, the present CMS allows previews of XBRL fact values (i.e., before publication into a finalised output). The user can check whether they have selected the correct fact attributes as they apply the tag, because the CMS is configured to display a preview of the XBRL fact value as it is transformed from the ‘displayed’ value in the report. This checking facility improves the human-machine interaction by enabling XBRL tags to be applied correctly when editing, thus obviating the need for a second software program to expend resources reviewing all tags as a separate reviewing process.

[0158] Another unique problem that will need to be solved as reporting regulations evolve is the need to handle the tagging and subsequent formatting of graphical content. Currently, tagging graphical content is not possible in PDF-conversion methods because graphical content is represented as an image in a PDF, and so individual elements of a graphic cannot be separately identified and tagged. As before, any tags would have to be overlaid (as a separate layer) to the graphical content, and so the tags would be entirely dissociated from the underlying graphical content. Moreover, once outputted into a PDF format, the arrangement of the graphical elements (and the arrangement of any overlaid tags) is fixed, and so the graphic is not accessible and cannot be adapted to be displayed in different layouts or devices, such as on a mobile device screen.

[0159] Due to the fact that the presently-disclosed CMS is native to HTML, the inventors have established a method to tag graphical content in a compliant and accessible manner. Moreover, as described below, the present CMS can tag graphical content in a manner that allows the tags to be persistently associated with the relevant graphical element irrespective of the publication format or display device. The ability to tag graphical content is advantageous generally, and indeed may be required for current and future regulations such as new sustainability reporting regulations. Nevertheless, it is emphasised that the graphical tagging methods described herein are not intended merely to meet regulatory requirements, but also provide a solution to the technical problems associated with known methods. Thus, the presently disclosed graphical tagging methods are able to reduce the computing resources (and number of different software packages) needed to perform graphical tagging, improve the user-machine interaction for implementing and revising graphical editing. Present methods also allow tagged graphical content to be readable and accessible on a variety of electronic devices and in a variety of publication formats, which is currently not possible.

[0160] Figure 7 illustrates some graphical content that could be tagged, in this case a business plan 700a. The business plan 700a on the left-hand side represents the originally-designed form of the graphic. It is important to note that a graphic, such as this business plan, needs to be treated as a single item which should be tagged as a single disclosure. In addition to this, it would be advantageous to separately tag multiple elements within the graphic, e.g., sub-sections (702, 704, 706, 708) and charts / diagrams (710).

[0161] In current methods that rely on PDF conversion, the graphic 700a would be stored as an image where the distinct subs-sections and diagrams are simply stored as pixels within the image, and so a computer cannot identify them as separate elements. As a result, such an image is not accessible, not fully screen-readable, not text taggable, and is not responsive to being displayed in different layouts such as on a mobile device. RWR01-133927PC

[0162] Using the presently-disclosed CMS method, no conversion of the graphic 700a into another image-based format is necessary. Instead, each element of the graphic, which is encoded as an HTML / CSS element, is maintained in that format. As such, it is possible to form an outer container around the graphic 700a that can be tagged as a single unit. Within this unit 700a (in a similar manner to the nested tagging disclosed above) more containers can be formed around each paragraph 702, 704, 706, 708 and any charts 710, and separately tagged. Consequently, the present method permits a persistent association to be created between tags and graphical elements that make up a graphic. Moreover, the present method permits a hierarchy of the tags to be recorded, e.g., it is possible to convey that the tags for each paragraph are nested within the tag applied to the overall contained of the graphic 700a. It should be appreciated that a ‘graphical element’ within a graphic may be an image, but may alternatively may comprise (or consist entirely of) text, or tabular content for storing numerical values.

[0163] Furthermore, since the containers for each element and the tags are encoded with HTML / CSS, the format of the graphic is readily adaptable to different layouts, publication formats, and electronic displays. The tags, persistently associated with each container, move with any rearrangements applied to the graphic. Figure 7 shows a second layout 700b of the same graphic, where this alternative format 700b is representative of a display on a mobile device. Here, each container for each graphical element (702, 704, 706, 708, 710) has been automatically rearranged in order to fit into a portrait orientation. Because the graphic is stored as separate HTML / CSS elements, the graphic can be readily deconstructed and rearrangement in any desired format. Unlike in known methods, neither the position of the container elements nor the tags are fixed. However, the layout order of the elements is encoded within the HTML / CSS representation of the graphic meaning that the order (e.g., the intended reading order) of the containers in both the desktop graphic 700a and the mobile graphic 700b is preserved. Further advantageously, since the XBRL tags are persistently associated with the container elements, the tags are automatically rearranged, and the resulting rearrangement 700b is just as accessible as the original 700a. It should also be appreciated that the underlying HTML / CSS representation is agnostic to the format of the original design. For example, the graphic in Figure 7 could be designed in the CMS-based editor in the first instance in the mobile device format 700b, and subsequently rearranged to a desktop display format 700a.

[0164] The terms computer program code and computer-readable instructions as used herein refer to any kind of executable code for processors, including code expressed in a machine language, an interpreted language or a scripting language. Executable code includes binary code, machine code, bytecode, code defining an integrated circuit (such as a hardware description language or netlist), and code expressed in a programming language code such as C, Java or OpenCL. Executable code may be, for example, any kind of software, firmware, script, module or library which, when suitably executed, processed, interpreted, compiled, or executed at a virtual machine or other software environment, causes a processor of the computer system at which the executable code is supported to perform the tasks specified by the code. The terms computer program code and computer readable instructions are also intended to encompass software which defines a configuration of RWR01-133927PC hardware as described herein, such as HDL (hardware description language) software, as is used for designing integrated circuits, or for configuring programmable chips, to carry out desired functions.

[0165] A processor, computer, or computer system may be any kind of device, machine or dedicated circuit, or collection or portion thereof, with processing capability such that it can execute instructions. A processor may be or comprise any kind of general purpose or dedicated processor, such as a CPU, GPU, NNA, System-on- chip, state machine, media processor, an application-specific integrated circuit (ASIC), a programmable logic array, a field-programmable gate array (FPGA), or the like. A computer or computer system may comprise one or more processors. A processor, computer, or computer system may comprise or be associated with one or more memories. For example, a bank of memory comprising at least one memory may be coupled to one or more processors.

[0166] Some portions of the above description present features in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. These operations, while described functionally or logically, are understood to be implemented by computer programs. Furthermore, the reference to these arrangements of operations in terms of modules should not be considered to imply a structural limitation and references to functional names is by way of illustration and does not infer a loss of generality.

[0167] Unless specifically stated otherwise as apparent from the description above, it is appreciated that throughout the description, discussions utilising terms such as "processing" or "identifying" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, or one or more processor of such a computer system or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission or display devices.

[0168] In this disclosure, when the subject of a phase is described as being "configured to" or “arranged to”, followed by a term defining a condition or function, this is used to indicate that the subject of the phrase is in a state in which it has that condition, or is able to perform that function, without the subject being modified or further configured.

[0169] Some implementations may be described using the expressions “one / an embodiment” or “one / an implementation” or “one / an example”, along with their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in some implementations” in various places in the specification are not necessarily all referring to the same embodiment. Moreover, unless otherwise noted the features described above are recognized to be usable together in any combination. Thus, any features discussed separately may be employed in combination with each other unless it is noted that the features are incompatible with each other. RWR01-133927PC

[0170] The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant indicates that aspects of the present disclosure may consist of any such individual feature or combination of features. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the appended claims.

[0171] The foregoing description of example embodiments has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the present disclosure to the precise forms disclosed. Many modifications and variations are possible in light of this disclosure. It is intended that the scope of the present disclosure be limited not by this detailed description, but rather by the claims appended hereto. Future filed applications claiming priority to this application may claim the disclosed subject matter in a different manner and may generally include any set of one or more limitations as variously disclosed or otherwise demonstrated herein.

[0172] The following terms used in the present disclosure are registered trade marks (RTMs): InDesign, Excel, Workiva, Word, Oracle Hyperion, OneStream, Tagetik.

Claims

RWR01-133927PCCLAIMS1. A computer-implemented method for generating an electronically publishable structured document, wherein generation of the document is performed using XHTML on a content management system, CMS, the method comprising: on the CMS, generating a draft document in an XHTML format by: generating content comprising at least one of i) written text ii) a table for storing numerical data, and iii) graphical elements; generating a plurality of XBRL tags, and assigning each XBRL tag to a portion of the content; generating a persistent association between each assigned XBRL tag and its respective content portion, wherein the persistent association is visible to a user editing the draft document on the XHTML platform, and wherein the persistent association defines i) a positional relationship between each XBRL tag and its respective content portion that is configured to respond to edits of the content of the draft document and ii) a position of the XBRL tag relative to the assigned content portion in the subsequently published document; exporting, using the CMS, the draft document comprising the plurality of XBRL tags and the persistent associations from the XHTML format to obtain a plurality of structured documents each having a different format, including at least one electronically publishable format and at least one print format, the electronically publishable formats comprising at least: XHTML, and PDF.2 The method of claim 1 , wherein the CMS is configured to enable a plurality of design controls for written text and for cells forming part of a table, wherein the plurality of design controls comprise: paragraph text styles in cells, hyperlinks in cells, super-scripts or sub-scripts in cells, and typographic design including spacing, colour, and fonts.3 The method of claim 1 or 2, wherein the draft document comprises one or more graphical elements, wherein the CMS is configured to design and encode each graphical element using CSS, wherein the design of the graphical element is thereby preserved in each of the print format and the electronically publishable formats.4 The method of any preceding claim, further comprising: generating a table in the draft document, and assigning at least one XBRL tag to a portion of the table; obtaining numerical data from a source external to the HTML platform; and populating the table with the obtained numerical data.5 The method of any preceding claim, further comprising: prior to exporting the draft document, validating an accuracy of the draft document comprising generating an error flag indicating i) an error type and / or ii) a location of the error within the document, whereinRWR01-133927PC the accuracy of the draft document pertains to one or more of: an accuracy of the HTML code, an accuracy of an XBRL tag, and an accuracy of a numerical entry in a table within the draft document.

6. The method of claim 5, wherein validating the accuracy of the draft document comprises determining a technical correctness of one or more XBRL tags, the determining comprising, for each of the one or more XBRL tags: determining a concept and / or type of the XBRL tag; determining that a mismatch exists between a concept and / or type of the content portion to which the XBRL tag is assigned; generating the error flag in response to the determination of the mismatch.7 The method of any preceding claim, further comprising: generating one or more further XBRL tags and assigning the one or more further tags to a block of content, wherein the block of content is a content portion to which at least one tag, of the plurality of XBRL tags, has already been assigned; wherein the one or more further XBRL tags are different to the already assigned at least one tag.8 The method of any preceding claim, further comprising, on the HTML platform and prior to exporting the draft document: including a cross-reference indication in a portion of the content, the cross-reference indication indicating one or more content portions of the draft document; generating a persistent cross-reference association between the cross-reference indication and each of the one or more content portions, wherein the persistent cross-reference association is configured to define a relationship with of each of the one or more content portions in the subsequently published document.9 The method of any preceding claim, wherein the HTML platform is an xHTML platform, the electronically publishable format of the structured document is xHTML, and the written content and the plurality of XBRL tags are electronically searchable in the obtained structured document.10 The method of any preceding claim, further comprising, on the XHTML platform and prior to exporting the draft document: generating one or more further XBRL tags; assigning each of the one or more further XBRL tags to a subset of a content portion , wherein the content portion has already been assigned an XBRL tag of the plurality of XBRL tags; generating a persistent association between i) the further XBRL tag and the subset of the content portion, and between ii) the further XBRL tag and the already-assigned XBRL tag.11 The method of claim 10, wherein the already-assigned XBRL tag is assigned to a table for storing numerical data, and the one or more further XBRL tags are assigned to respective cells or data entries within the table.RWR01-133927PC12. The method of any preceding claim, further comprising: after assigning each XBRL tag to a content, displaying, on a graphical user interface within the draft document, a fact value of each of the assigned XBRL tags.

13. The method of any preceding claim, further comprising, on the HTML platform and prior to exporting the draft document: determining a concept and / or a type of a plurality of assigned XBRL tags assigned to content portions containing a numerical value; determining that an error exists in a value or sign of a numerical value in dependence on the concept and / or type of the XBRL tag assigned to that value; in response to determining the mismatch, indicating or applying a correction to the value or sign of the numerical value.

14. The method of any preceding claim, further comprising: subsequent to generating each of the persistent associations between each assigned XBRL tag and its respective content portion, editing a portion of the content to obtain an edited draft document; exporting the edited draft document to obtain an edited structured document in electronically publishable format, wherein the edited structured document comprises the persistent associations, and wherein a position of each assigned XBRL tag in the edited structured document is co-located with its respective content portion in dependence on the persistent associations.

15. A computer program comprising a program code for performing the method according to any of claims 1 to 14 when executed on a computer.

16. A system for generating an electronically publishable structured document, the system comprising one or more processors and an XHTML content management system, CMS, for generating a draft document, the system configured, in an XHTML format, to: receive input to thereby generate content comprising at least one of i) written text and ii) a table for storing numerical data; receive input to thereby generate a plurality of XBRL tags, receive input to assign each XBRL tag to a portion of the content; generate a persistent association between each assigned XBRL tag and its respective content portion, wherein the persistent association defines i) a positional relationship between each XBRL tag and its respective content portion that is configured to respond to edits of the content of the draft document and ii) a position of the XBRL tag relative to the assigned content portion in the subsequently published document; display the persistent association to a user using the CMS, and export, using the CMS, the draft document comprising the plurality of XBRL tags and the persistent associations from the XHTML format to obtain a plurality of structured documents each having a different format,RWR01-133927PC including at least one electronically publishable format and at least one print format, the electronically publishable formats comprising at least: XHTML and PDF.

17. The system of claim 16, wherein the system further comprises a memory storing an XBRL taxonomy module, the XBRL taxonomy module including one or more of: an XBRL extension taxonomy having XBRL extension taxonomy concepts and / or types, and an XBRL base taxonomy having related XBRL base taxonomy concepts and / or types.

18. A computer-implemented method for generating an electronically publishable structured document containing graphics, wherein generation of the document is performed using XHTML on a content management system, CMS, the method comprising: on the CMS, generating a draft document in an XHTML format by: generating content comprising at least one graphic, the graphic comprised of a plurality of graphical elements and represented using HTML and / or CSS; generating a plurality of XBRL tags and, using the generated plurality of XBRL tags, assigning an XBRL tag to the graphic and assigning at least one XBRL tag to at least one respective graphical element within the graphic; generating a persistent association between each assigned XBRL tag and its respective portion of the graphic, wherein the persistent association is visible to a user editing the draft document on the XHTML platform, and wherein the persistent association defines i) a positional relationship between each XBRL tag and its respective content portion that is configured to respond to edits of the content of the draft document and ii) a position of the XBRL tag relative to the assigned portion of the graphic in the subsequently published document; exporting, using the CMS, the draft document comprising the plurality of XBRL tags and the persistent associations from the XHTML format to obtain a plurality of structured documents each having a different format, including at least one electronically publishable format and at least one print format, the electronically publishable formats comprising at least: XHTML and PDF.

19. The method of claim 18, wherein each graphical element may be formed of content selected from one or more of: text; tabular content; and an image.

20. The method of claim 18 or 19, wherein generating the draft document further comprises: generating content comprising at least one of i) written text and ii) a table for storing numerical data; generating a further plurality of XBRL tags, and assigning each generated XBRL tag to a portion of the content; generating a persistent association between each assigned XBRL tag and its respective content portion.

21. The method of any of claims 1 to 14 or 18 to 20, wherein generating the draft document comprises providing a graphical user interface and performing, by an end user using the graphical user interface, the steps of generating the content, generating the plurality of XBRL tags, and assigning the generated XBRL tags.RWR01-133927PC22. A system for generating an electronically publishable structured document containing graphics, the system comprising one or more processors and an XHTML content management system, CMS, for generating a draft document, the system configured, in an XHTML format, to: receive input to thereby generate content comprising at least one graphic, the graphic comprised of a plurality of graphical elements and represented using HTML and / or CSS; receive input to thereby generate a plurality of XBRL tags; receive input to assign, using the generated plurality of XBRL tags, an XBRL tag to the graphic and assign at least one XBRL tag to at least one respective graphical element within the graphic; generate a persistent association between each assigned XBRL tag and its respective portion of the graphic, wherein the persistent association is visible to a user editing the draft document on the XHTML platform, and wherein the persistent association defines i) a positional relationship between each XBRL tag and its respective content portion that is configured to respond to edits of the content of the draft document and ii) a position of the XBRL tag relative to the assigned portion of the graphic in the subsequently published document; display the persistent association to a user using the CMS, and export, using the CMS, the draft document comprising the plurality of XBRL tags and the persistent associations from the XHTML format to obtain a plurality of structured documents each having a different format, including at least one electronically publishable format and at least one print format, the electronically publishable formats comprising at least: XHTML, and PDF.

Images