FRA XBRL filer manual (platform edition)

How the platform produces, accepts and checks XBRL. It follows the XBRL International specifications and current regulator practice (ESMA ESEF, SEC EDGAR, EBA), adapted for the Egyptian Financial Regulatory Authority.

1. Specifications

Next versions (Taxonomy Packages 1.1, Report Packages 1.1, Project Tavi): docs/xbrl/ROADMAP.md.

2. Taxonomy

• Base: IFRS Accounting Taxonomy 2025-03-27 (https://xbrl.ifrs.org/taxonomy/2025-03-27/ifrs-full). Only the element schema is imported, as ESEF does, not the IFRS entry point: the IFRS calculation networks (for example, both balance-sheet layouts) are not the filer's.
• FRA extension: published by the platform at /xbrl/taxonomy/{version}/… and as a Taxonomy Package at /xbrl/taxonomy/fra-taxonomy-{version}.zip (both with CORS, section 2.7).

2.1 Namespaces (XB-TAX-002)

One namespace and one schema ({prefix}-{version}.xsd) per supervised domain, under http://xbrl.fra.gov.eg/taxonomy/{version}/{prefix}:

The elements a domain declares are its templates' fields plus the curated list in resources/xbrl/extension-elements.php (types, period types, balances, labels, documentation).

Legacy prefixes fra-ci and fra-eas. The platform's pre-2025 concept registry (served by GET /api/v1/xbrl/concepts and used by the KPI services) is unchanged, but its prefixes are not namespaces of this taxonomy and no filing is tagged with them. Their equivalence to published elements is in resources/xbrl/legacy-aliases.php, published as fra-{version}-legacy-aliases.json (equivalent, closest with the difference noted, or none — e.g. fra-eas:EBITDA, a non-GAAP measure with no element).

2.2 Entry points per report type (XB-TAX-003)

A report type is template × sector × consolidated/separate × periodicity, on IAS 1 and on IFRS 18 (section 10). Each has its own entry point:

fra-{version}-{template}[-ifrs18].{sector}.{basis}.{periodicity}.xsd — e.g. fra-2025-fra-fin-insurance.ins.consolidated.annual.xsd, fra-2025-fra-fin-cis-ifrs18.egx.consolidated.interim.xsd.

A report-type entry point loads only its own networks: the template's presentation, calculation and definition networks; the document-and-entity-information (cover) network; its sector's supplement network (the elements of that sector's namespace); the notes network (text blocks) on annual entry points only; and the formula assertions that apply to that set of elements (…{sector}_for.xml, or the template's …report_for.xml when the sector adds none — e.g. only insurance entry points carry FRA_INS_SOLVENCY). The basis is enforced by the hypercube: a consolidated template's figures cannot carry SeparateMember; a separate template's must (the consolidated default member is not usable).

Every filing references its report-type entry point (artifacts.report_type on the document). The per-template entry points (fra-{version}-{template}[-ifrs18].xsd) remain published so filings generated before still resolve, and Channel D recognises both forms. fra-entry-{version}.xsd is the whole taxonomy (IAS 1), for browsing. XBRL_REPORT_TYPE_ENTRY_POINTS=false reverts filings to the per-template entry points.

• Dimension defaults are declared once, in fra-{version}_def-defaults.xml, which every entry point loads.
• Loading IFRS: IFRS element definitions are loaded from the IFRS Foundation's published schema with php artisan fra:xbrl:import-ifrs.

2.3 Labels (XB-TAX-004)

• fra-{version}_lab-ar.xml gives an Arabic standard label to every element any network uses, IFRS elements included: the wording of the template field tagged with it, else FRA's dimension and note tables, else resources/xbrl/ifrs-labels-ar.php. English labels of IFRS elements are the IFRS Foundation's (both IFRS label linkbases are referenced); fra-{version}_lab-en.xml labels every extension element.
• Documentation labels (Arabic and English) on every extension element, citing the source (FRA rule, IAS / IFRS S2 paragraph); terse labels where a short caption helps (e.g. AuditOrReviewStatus); total labels on the totals of the calculation networks, used as the presentation arc's preferredLabel on total lines.
• Provenance: fra-{version}-labels-review.csv lists the source of every Arabic IFRS label: template, fra, or mt — machine-assisted translation, to be reviewed by FRA's terminology committee. No element is left without an Arabic label (a test enforces it).

2.4 Link roles and generic labels

Extended link roles follow the Link Role Registry conventions used by IFRS and ESEF: a URI under the taxonomy namespace and a definition [sort code] Group - Title (Document, Statement, Disclosure, Supplement, Enumeration), defined once in fra-roles-{version}.xsd. Each role has Arabic and English generic labels (Generic Labels 1.0) in fra-{version}_gla-{ar,en}.xml; each formula assertion has Arabic and English generic labels naming it.

2.5 Enumerations (Extensible Enumerations 2.0)

List-valued disclosures are enum2:enumerationItemType elements whose value is a member of a domain network in its own role (fra-{version}_enum_def.xml, linked from fra-{version}.xsd):

In XBRL 2.1 and Inline XBRL the value is the member's expanded name ({namespace}#{localName}); in xBRL-JSON and xBRL-CSV it is the member QName (ifrs-full:SeparateMember), as OIM requires.

2.6 Regional mapping table (XB-TAX-010, XB-TAX-013)

fra-{version}-regional-alignment.csv / .json (in the package) and the public page /xbrl/taxonomy/alignment (?format=csv|json) list every element the taxonomy uses with:

• source_taxonomy, source_edition, source_verified — the taxonomy and edition that declare it (IFRS Accounting Taxonomy 2025-03-27, IFRS Sustainability Disclosure Taxonomy 2024-04-26, FRA taxonomy {version}) and whether it is declared in the imported schema of that edition;
• ifrs_element and match — exact (it is the IFRS element), wider / narrower (the IFRS anchor of an FRA extension element, section 2.9), none;
• per regulator (KSA, UAE, OMN, JOR) a status and the regulator's element: verified (the regulator's taxonomy, loaded with php artisan fra:xbrl:import-regional {KSA|UAE|OMN|JOR} --dir=<unpacked package> --taxonomy=… --edition=…, declares or imports the same element in the same namespace), verified-other-edition, absent, unverified (the regulator's taxonomy is not loaded — the expected element is not assumed to exist) or none.

No regional taxonomy package is bundled with the platform: until FRA loads one, its column reads unverified.

2.7 Hosting (XB-TAX-009)

Files (.xsd, .xml, and the .csv / .json resources), packages and the index are served with Access-Control-Allow-Origin: *, Access-Control-Allow-Methods: GET, HEAD, OPTIONS and exposed Content-Disposition, X-Content-SHA256; OPTIONS preflight answers 204.

2.8 Sustainability entry point (XB-TAX-011)

fra-{version}-issb.xsd is a separate entry point for sustainability-related disclosures on the official IFRS Sustainability Disclosure Taxonomy (IFRS Foundation, edition 2024-04-26, namespace https://xbrl.ifrs.org/taxonomy/2024-04-26/ifrs-sds, prefix ifrs-sds): it imports the official core schema (https://xbrl.ifrs.org/taxonomy/ifrs_sds/2024-04-26/ifrs_sds/ifrs_sds-cor_2024-04-26.xsd) and English label linkbase, and presents the IFRS S1/S2 elements FRA uses (statement of compliance, governance, strategy and risk management, Scope 1/2/3 GHG emissions, climate-related transition and physical risks, capital deployment, carbon price, remuneration, carbon credits — resources/xbrl/issb-elements.php), with FRA Arabic labels (fra-{version}-issb_lab-ar.xml), and the platform's ESG/carbon template elements beside them. Element names, item types and period types are copied from the official schema; php artisan fra:xbrl:import-issb loads the full official element list and fails if the list ever drifts from it. fra-{version}-issb-mapping.json maps the template elements to the official ones (exact, wider, none) and the fra-issb stand-ins of taxonomy versions before 2026.10.15 to their official replacements. Other entry points do not load the ISSB schema.

2.9 EAS differences and anchoring (XB-TAX-001)

The FRA entry points import the IFRS element schema only, never the IFRS entry points' calculation networks. The IFRS 2025 calculation networks are nevertheless imported (fra:xbrl:import-ifrs reads every cal_*.xml the IFRS entry point links) as reference data: each FRA calculation relationship is classified against them (ifrs-same, ifrs-descendant, fra-only, weight-conflict) in fra-{version}-ifrs-calculation-alignment.csv.

Where the Egyptian Accounting Standards treat a line item differently from IFRS and IFRS therefore has no element, the fra-egs namespace declares one, with Arabic and English labels and documentation of the difference: employees' share of profit and board remuneration distributed from equity (Companies Law 159 of 1981; IAS 19 treats it as an expense) and its payment in financing cash flows, and the exchange differences of the EAS 13 special treatment (recognised in OCI or capitalised). The template lines concerned are tagged with them (XBRL_EAS_EXTENSIONS, default on). Where IFRS has the element, no extension is made (legal reserve: ifrs-full:StatutoryReserve; transfer to it: IncreaseDecreaseThroughTransferToStatutoryReserve).

Every extension element carries an anchoring decision (resources/xbrl/extension-anchors.php): the closest IFRS element, wider or narrower, published as fra-{version}_def-anchoring.xml with the arcrole http://xbrl.fra.gov.eg/arcrole/wider-narrower (declared in fra-roles-{version}.xsd#wider-narrower with cyclesAllowed="undirected", definition wider-narrower (anchoring of extension elements) and usedOn link:definitionArc — a filer extension that declares the arcrole itself must declare exactly this, XBRL 2.1 §5.1.4 — the arcrole filer extensions use, section 4), or none with the reason (register data, prudential measures).

2.10 FRA-authored rules as Formula assertions (FR-VAL-005)

Rules FRA staff publish in the admin rule stores (financial validation rules: arithmetic over line items within a tolerance; XBRL validation rules: a {Concept} expression against a threshold) are translated into XBRL Formula 1.0 value assertions FRA_ADMIN_<code> in the formula linkbases of the entry points they apply to (template- and sector-scoped), with Arabic and English messages and severity. A line item named by label is resolved to the element the templates tag it with; a rule is published only when every operand resolves to exactly one element. fra-{version}-admin-rules-formula.json lists every rule with its assertion test or the reason it cannot be expressed (ambiguous label, no element, one element at two dates, structural check with no expression…). Drafts and retired rules are never published.

3. Report conventions

4. Filing XBRL (Channel D)

A company files an XBRL report produced by its own tagging tool in two ways, with the same intake and the same validation:

• Portal: in the filing wizard, upload an Inline XBRL report (.xhtml/.html), an XBRL 2.1 instance (.xbrl/.xml), xBRL-JSON (.json) or a report package (.xbri/.xbr/.zip). An xBRL-CSV report and a multi-document Inline XBRL report are uploaded as a package (section 15).
• API: POST /api/v1/filings/submit with the report (or the raw bytes of the package) as the encrypted plaintext. A report that references an FRA entry point, any package and any xBRL-JSON/CSV report is read in standard mode (xbrl_mode: standard). The IR platform's earlier format — fra:DynamicField_N facts without an FRA entry point — is still accepted as a legacy mode (xbrl_mode: legacy_dynamic_fields, facts read by label, not validated as standard XBRL) while the FRA keeps XBRL_API_LEGACY_MODE=allow; with reject it is refused (legacy_format_rejected). New integrations must use standard mode.

How the report is read:

• Template: taken from the FRA entry point the report references (IAS 1 or IFRS 18); a report on its own extension schema is traced through that schema's import; otherwise the template chosen in the wizard.
• Entity: the report's identifier must match the company's FRA licence number or LEI (FRA-102). The check is never skipped: a company whose profile has neither is refused (FRA-103) until it completes its profile, unless the FRA recorded an override for it (php artisan fra:xbrl:entity-override).
• Mapping:
  • facts are bound to template fields by element, period and dimension members, never by label — the same tagging the platform generates (section 12);
  • current and comparative year are told apart by date; an opening balance is the day before the period;
  • an IFRS 18 element fills the field of its IAS 1 counterpart and vice versa;
  • a deprecated element is read as its replacement, with a warning (FRA-126, section 11);
  • two facts that bind to the same field and period with different values are an error (FRA-124) — the platform never keeps «the first value»;
  • dimensional detail with no template field (FRA-127) and elements with no template field (FRA-123) are reported as warnings.
• Result: a report with any error is refused with the list of findings; nothing is filed. A report with warnings only is filed and its warnings are shown to the company and to the FRA reviewer. Every validation is stored (per filing version) and is part of the FRA validation report (section 5).

5. Validation

Every report is validated in the layers of the FRA RFP (§7.5), in this order. Each finding carries a numbered rule id, its layer, its severity and its message in Arabic and English. The rule set is versioned (XBRL_RULES_VERSION, currently 2026.10.1) and published as a machine-readable rules file:

• GET /xbrl/filer-manual/rules.json — JSON: version, layers, policies (Calculations 1.1, duplicates, anchoring) and rules[] with id, layer, severity (and severity_now under the current configuration), message.ar/message.en (with {placeholders}), description, effective_from, effective_to, specification, configurable_by and the earlier native codes (legacy_codes). The same file is kept in the repository as docs/xbrl/fra-xbrl-rules.json (php artisan fra:xbrl:rules-export; CI checks it is up to date).
• This manual is served at GET /xbrl/filer-manual/manual (and …/manual.md).

Severities: error — the report is refused; warning — accepted, to be explained or corrected; info — information only.

5.1 Layers

1. Package safety — the upload is untrusted (section 15).
2. XBRL conformance — the platform's own reading (XBRL 2.1, Inline XBRL 1.1 incl. document sets, continuations and exclusions, OIM) and Arelle on the uploaded report itself, against the FRA entry point it references, resolved from the frozen FRA taxonomy package of that version. Arelle runs sandboxed: offline (XBRL_INTAKE_ARELLE_OFFLINE, taxonomies only from the FRA package, XBRL_ARELLE_PACKAGES and the warm cache), with a hard timeout (XBRL_INTAKE_ARELLE_TIMEOUT), on a private temporary copy. Any Arelle error (XBRL-100, with the Arelle message code) refuses the report. Where Arelle is not configured the run is reported (XBRL-102) — a warning, or an error when XBRL_INTAKE_ARELLE_REQUIRED=true.
3. Calculations 1.1 — round-to-nearest intervals from decimals, on the calculation network of the referenced entry point, and the balance-sheet identity.
4. Duplicate facts — XII WGN 2025-01-14: complete and consistent duplicates are accepted (DUP-003); inconsistent duplicates are errors (DUP-001, DUP-002).
5. FRA filing rules — FRA-101 … FRA-128.
6. Data quality — DQC-style rules DQ-001 … DQ-006.
7. FRA business rules — FRA-001 … FRA-006, FRA-W001 (on the published document of the filing) and the solvency assertion FRA_INS_SOLVENCY.

5.2 Calculations 1.1 policy

A total is consistent when the interval its decimals allow overlaps the interval of the weighted sum of its items reported in the same context and unit; a total with no item reported is not checked. The FRA policy for an inconsistency (CALC-001, XBRL_CALC_POLICY):

Arelle's own Calculations 1.1 messages on the upload are reported under CALC-001 too; the platform's check gives the tiered verdict with the amounts.

5.3 Extension elements and anchoring

A filer may declare its own elements in an extension schema inside its report package (as ESEF filers do). Every extension line item (a concrete xbrli:item that is not a domain member) must be anchored in the filer's definition linkbase: a definitionArc with the arcrole http://xbrl.fra.gov.eg/arcrole/wider-narrower (the ESEF arcrole http://www.esma.europa.eu/xbrl/esef/arcrole/wider-narrower is accepted too) from an IFRS or FRA element (the wider one) to the extension element (the narrower one). The anchor must have the same data type as the extension, or a type it derives from (monetaryItemType → monetaryItemType or decimalItemType). Unanchored: FRA-114; incompatible type: FRA-115; an element in an unknown namespace without schema: FRA-116. Severity: XBRL_ANCHORING_SEVERITY (default error).

5.4 Rules

Package safety (package)

XBRL specification conformance (xbrl)

Calculations 1.1 (calculation)

Duplicate facts (duplicates)

FRA filing rules (filing)

Data quality (data_quality)

FRA business rules (business)

5.5 Results

Results are stored per filing version and shown on the filing page, at /xbrl/filings/{id}/checks and in the FRA validation report (/fra/xbrl-documents/{id}/validation), exportable as JSON (…/validation/json) and PDF (…/validation/pdf): the report as filed (intake) and the published document (native checks, Arelle — messages, per-assertion results, xBRL-CSV pass — and the FRA business rules), bilingual, never recomputed or overwritten by the export.

Arelle on the published packages (when XBRL_ARELLE_CMD or XBRL_ARELLE_SERVICE_URL is set): each report package is checked against XBRL 2.1, Dimensions 1.0, Inline XBRL 1.1, Calculations 1.1 and duplicate facts, the formula assertions of its entry point are executed (--formula=run, section 9), the xBRL-CSV package is validated as a second report, and an interactive viewer (ixbrl-viewer) is generated for the filing. The stored report (arelle.report) holds the messages, the per-assertion results (assertions), the CSV pass (csv), how Arelle ran (mode, fallback), the time of all runs (total_ms) and the one-off validation of the taxonomy entry point (taxonomy_check, section 7).

6. Endpoints

7. Operations

• Configuration: config/xbrl.php. Set XBRL_ARELLE_CMD to the arelleCmdLine of a virtualenv with arelle-release and ixbrl-viewer. XBRL_ARELLE_CACHE sets the taxonomy cache folder (default storage/app/arelle-cache; a cache that does not persist costs ~45 s per run).
• Arelle performance (NFR-PERF-002): XBRL_ARELLE_SERVICE_URL — a long-lived arelleCmdLine --webserver on the loopback, called over HTTP, the CLI as fallback; XBRL_ARELLE_OFFLINE (no network once the cache is warm); XBRL_ARELLE_PACKAGES (extra taxonomy packages, |-separated); XBRL_ARELLE_BASE_VALIDATION (once: each FRA entry point is validated in full once per package content, reports then run with --baseTaxonomyValidation=none; always); XBRL_ARELLE_SERVICE_TIMEOUT. php artisan fra:xbrl:arelle-warm fills the cache. Measurements, the systemd unit and the install steps: docs/ops/arelle-service.md.
• Block tagging: XBRL_BLOCK_TAGGING (on/off), XBRL_BLOCK_TAGGING_SCOPE (annual default, all, none), XBRL_NOTE_MAX_CHARS (section 13).
• When reports are published: when a filing reaches FRA and when it is accepted (queued), and on demand from the filing page.
• Viewer script: public/vendor/ixbrl-viewer/ixbrlviewer.js (Apache-2.0), shared by every viewer.
• Other settings: XBRL_ARELLE_FORMULA (run/none), XBRL_SOLVENCY_MINIMUM, XBRL_SOLVENCY_SEVERITY, XBRL_IFRS18_EFFECTIVE_FROM, XBRL_SEPARATE_TEMPLATES.

8. xBRL-CSV

Every filing is also published as xBRL-CSV (OIM 1.0, documentType https://xbrl.org/2021/xbrl-csv):

• <name>-metadata.json — documentInfo (namespaces, taxonomy = the entry point or the filing's own extension), one table template facts and the table facts → <name>-facts.csv.
• <name>-facts.csv — one row per fact: id, concept, period (OIM form: an XBRL date is the end of that day), unit (empty for text and for xbrli:pure, as OIM requires), decimals, language, one dim_<axis> column per axis the report uses, value. All but value are parameter columns referenced by the template's dimensions ($concept, $period…); an empty cell leaves the property out.
• <name>.xbr — the two files in a non-inline Report Package 1.0 (https://xbrl.org/report-package/2023/xbr), validated by Arelle with the report.

Channel D reads xBRL-CSV from a package: template- and column-level dimensions, decimals, $column references, report-level dimensions/parameters, #none and #nil. Property groups and extends are not supported and are reported.

9. Formula assertions

Each entry point carries a Formula 1.0 linkbase (fra-{version}-{code}[-ifrs18]_for.xml, referenced from the entry point) with value assertions on the dimensional aspect model with implicit filtering (facts are compared within one context: same period, same members):

Every assertion has Arabic and English generic labels naming it, an Arabic and an English message for satisfied and for unsatisfied evaluations (XPath expressions in braces print the figures and the date), and its severity is an assertion-unsatisfied-severity arc to http://www.xbrl.org/2022/severities.xml. Tolerance is always the sum of the facts' rounding half-intervals. All of them are executed by Arelle on generated reports in the platform's test suite (tests/Feature/Rfp3/Xbrltax/XbrltaxArelleTest), including failing cases.

XULE is not used. Formula 1.0 is the XBRL International Recommendation implemented by every certified processor, and the FRA rules are value assertions it expresses directly; XULE is the XBRL US rule language (DQC rules) with essentially a single implementation. Rules that need procedural logic remain in the platform's native checks.

10. IFRS 18 entry points

IFRS 18 replaces IAS 1 for periods beginning on or after 1 January 2027. Each template has an IFRS 18 entry point whose presentation and calculation use the IFRS 18 element where it differs from IAS 1 (all present in the IFRS Accounting Taxonomy 2025, same balance and period type):

Finance income and costs stay on their IAS 1 elements: under IFRS 18 they split between the investing and financing categories according to what produced them, which the template does not record.

A filing is generated on the IFRS 18 entry point when its period begins on or after XBRL_IFRS18_EFFECTIVE_FROM (default 2027-01-01), or when the company elected early application (corporate_profiles.ifrs18_early_adoption, recorded by FRA on the taxonomy versions screen). The inline report states the framework; Channel D accepts both.

11. Taxonomy lifecycle

FRA administers taxonomy versions at fra/xbrl-taxonomy/versions:

1. Draft — version label (digits, letters, dots), release notes in Arabic and English, consultation window, effective date, and the elements the version deprecates with their replacements (or none) and the reason. Staff can download the draft package.
2. Consultation — needs the window; the package (with the version's own deprecations applied) is public at /xbrl/taxonomy/fra-taxonomy-{version}-DRAFT.zip, marked DRAFT in its name, metadata and a DRAFT-NOT-FOR-FILING.txt notice. Its files are not served individually.
3. Approved — by an officer with settings.manage who is not the version's author (maker-checker). The final package is built, frozen on disk and its SHA-256 recorded; it is served at /xbrl/taxonomy/{version}/… and as fra-taxonomy-{version}.zip (header X-Content-SHA256).
4. Effective — the previous effective version becomes superseded; it stays public so older filings still resolve.

A new version is a new namespace (http://xbrl.fra.gov.eg/taxonomy/{version}/…). A version label without a lifecycle record (the configured one, before FRA registers it) is served live from the templates. Deprecations of approved, effective and superseded versions bind: generation tags the field with the replacement (finding FRA.concept.deprecated) and intake reads the old element as the new one with a warning. Viewing needs taxonomies.view, editing taxonomies.manage, approval settings.manage.

Which version a filing is generated on.

1. The version in force for its period: of the effective and superseded versions, the one whose effective date is the latest on or before the filing's period end (a superseded version still binds the periods before its successor took effect: a FY 2025 report filed in 2026 stays on the 2025 taxonomy). Without one — no lifecycle yet, or a period ending before the first released version — the version in XBRL_FRA_VERSION. Approved versions do not bind until made effective.
2. The version is recorded on the XBRL document (taxonomy_version, and artifacts.fra_version) and shown on the filing's XBRL panel («تصنيف الهيئة {version}»).
3. Re-publishing keeps it. A filing is re-published (after a correction, a format change, a notes edit) on the version its latest document was generated with — never silently moved to a newer one. Moving it is an explicit regeneration: the panel offers «الإنشاء على الإصدار الساري {version}» when the version in force differs (POST /xbrl/filings/{id}/publish with regenerate=1).
4. Only the deprecations of versions effective on or before the filing's version apply to it.
5. Arelle validates the report against that version's package — the frozen package of a released version, the live one (stored once per content) for the configured version — and its files are served per version at /xbrl/taxonomy/{version}/…. GET /xbrl/taxonomy reports as current the version in force today.

12. Dimensions

Each template's definition linkbase (…_def.xml, in the template's role) makes the statement heading the primary item of a closed hypercube (contextElement="segment") and every template element its domain member. The statement of changes in equity also has a calculation network: ChangesInEquity = its movements (profit, OCI, dividends −, issue of equity, transfers…), checked within each component's context.

• Statement of changes in equity. The templates file one column per year: opening balances by component, movements, closing balances. A component balance is tagged ifrs-full:Equity with its ComponentsOfEquityAxis member — at the day before the period for an opening balance, at the period end for a closing one (this year's opening is last year's closing: one fact). Total equity carries no member. Movements the templates tag with balance or cash-flow elements get the IFRS movement element of the component they change (dividends → DividendsRecognisedAsDistributionsToOwnersOfParent [retained earnings], transfers → IncreaseDecreaseThroughTransfersAndOtherChangesEquity [other reserves], capital increase → IssueOfEquity [issued capital], treasury shares, NCI changes). There is no calculation network: sums across an axis are not calculations.

• Segments. A line filed with a segment (segment on the extracted line) gets a member declared in the filing's own extension (<name>.xsd importing the template's entry point, _def.xml placing the members under SegmentsDomain in the template's role, _lab.xml with Arabic and English labels), as ESEF filers do. The report references that schema; the files travel in the packages and are served next to the report.

• Insurance classes. A line filed with a class of business (insurance_class: motor, fire, marine, engineering, health, life, other — or the Arabic name) gets its fra-ins member.

• Entering segment and class figures. On the filing page (section «بيانات XBRL الإضافية», while the filing is a draft or returned for amendment) the company fills two grids:

  • Operating segments — each segment's Arabic and English name (the English name, Latin characters, gives the member's local name, e.g. RetailSegmentMember; an Arabic-only name gets a stable hashed one) and its figures for the current and prior year for the IFRS 8 measures its template carries: revenue (Revenue / RevenueFromContractsWithCustomers), profit before tax, profit (ProfitLoss), total assets, total liabilities. Offered only on templates whose hypercube has the segments axis (a profit-or-loss statement or insurance elements) — the hypercube is closed, so a figure on any other element would be dimensionally invalid.
  • Insurance classes — the seven FRA classes (fra-ins:…Member) × the template's monetary fra-ins figures (gross written premium, net claims incurred, technical reserves). Ratios are not entered by class.

  Empty cells are not reported (they are not zeros); printed negatives (50,000) and Arabic digits are accepted. On an axis the company filled, these figures replace any detail lines the extraction produced on that axis. The page shows, per figure and year, the sum of the members against the entity's own figure; the native checks raise FRA.segments.reconcile / FRA.insuranceClasses.reconcile (warning) when they differ beyond rounding — reconciling items are allowed by IFRS 8.28 but must be explained. Calculations 1.1 relationships of the template apply within each member's context as for the entity figures (natively and in Arelle): e.g. a segment reporting both profit before tax and its components is checked.

• Contexts carry the members in all syntaxes (XBRL 2.1, Inline XBRL, xBRL-JSON, xBRL-CSV); context ids name them (I20251231_Separate_IssuedCapital), and the platform's checks key facts by the full context.

13. Block tagging of the notes (XB-GEN-007)

Every note and accounting policy of an annual filing is tagged in the XBRL report as an IFRS text block (dtr-types:textBlockItemType), as ESEF requires:

• Where the text comes from. The filing page (section «بيانات XBRL الإضافية») keeps one entry per note: kind (note / accounting policy), number, Arabic and English caption, the IFRS element, and the text. «استخراج الإيضاحات من ملف PDF» proposes them from the source PDF: the extraction's notes catalogue (note number → page, caption, kept in the extraction job's doc_intelligence) locates each note, and its text is the PDF's text layer from its heading to the next note's heading (visual-order Arabic lines restored, page numbers dropped). A scanned PDF has no text layer and no catalogue: nothing is proposed and the company pastes the notes. Imported notes are marked «من ملف PDF — يحتاج مراجعة»; existing note numbers are kept.
• Text format. A blank line separates paragraphs; a line break is kept. A run of lines with tabs (pasted from a spreadsheet) or | (a markdown table; the |---| separator row is dropped) is a table.
• Which element. The company may choose the element; otherwise the caption decides, through a table of 84 elements of the IFRS Accounting Taxonomy 2025 (each name checked against full_ifrs-cor_2025-03-27.xsd) with the Arabic and English caption words of the notes Egyptian filers publish: general information, basis of preparation, judgements and estimates, property plant and equipment, investment property, intangible assets, subsidiaries, associates, financial investments, inventories, receivables, cash, issued capital, reserves, borrowings, leases, provisions, employee benefits, payables, income and deferred tax, contingencies, revenue, cost of sales, administrative expenses, finance income/costs, EPS, dividends, related parties, fair value, risk and capital management, insurance contracts, reinsurance, events after the reporting period… (50 note elements) and 33 DescriptionOfAccountingPolicyFor… elements. Captions are compared after folding Arabic letter forms and joined prepositions («للأصول» = «الأصول»). A caption saying «السياسة المحاسبية» is a policy. Unrecognised notes go to ifrs-full:DisclosureOfAdditionalInformationExplanatory, unrecognised policies to ifrs-full:DisclosureOfMaterialAccountingPolicyInformationExplanatory.
• One fact per element. Notes tagged with the same element (two provisions notes, the unrecognised ones) form one fact: in Inline XBRL an ix:nonNumeric on the first and ix:continuation on the others, chained by continuedAt; elsewhere their XHTML concatenated in report order.
• Syntaxes. Inline XBRL: a «الإيضاحات المتممة للقوائم المالية» section after the statements, each note under its caption, its body inside ix:nonNumeric escape="true" (xml:lang from the text) — the value is the escaped XHTML of the content. xBRL-XML: the escaped XHTML (<p>…</p><table>…</table>) as the fact value; xBRL-JSON and xBRL-CSV: the same string, with language. The context is the current period, on the template's consolidation member (separate statements: SeparateMember), like its figures. Text-block facts are not repeated in ix:hidden. The facts table keeps the first 60,000 bytes of a long note (the report files keep it whole).
• Phase-in. XBRL_BLOCK_TAGGING_SCOPE=annual (default): filings covering a full year (no quarter, a period of at least eleven months). Interim filings keep their notes but they are not tagged (finding FRA.notes.phaseIn, info) until FRA sets all. XBRL_BLOCK_TAGGING=false turns block tagging off.
• Validation. Arelle validates the text blocks with the report (Inline XBRL rules for escaped content and continuations): 0 errors on the demo filings.

14. Format versions

XbrlPublisher::FORMAT and FraTaxonomy::FORMAT are 2026.10.14 (2026.10.10: report-type entry points, enumerations, report-level and comparability facts, formula rules; 2026.10.14: decimals from the declared presentation scale, the XB-TAX-011 reporting flags, dtr-types:ghgEmissionsItemType for emissions): documents of an earlier format are regenerated on their own taxonomy version when next served. A golden-file test (XbrlWriterGoldenAndViewerTest, tests/Fixtures/xbrl/golden/writer-output.json) fails when a writer's output changes without a FORMAT bump.

Deterministic generation (XB-GEN-008). The files carry no generation timestamp: the same facts and the same generator version give byte-identical Inline XBRL, XBRL 2.1, xBRL-JSON, xBRL-CSV and report packages (zip entries have a fixed timestamp and order), and the taxonomy package is byte-identical for the same templates (tp:publicationDate is XBRL_FRA_PUBLICATION_DATE, else the day the templates last changed). When and by which generator a document was produced is recorded on the document row (artifacts.generated_at, artifacts.generator), outside the files and the facts hash.

15. Packaging and naming

Report packages (Report Packages 1.0): a ZIP with a single top-level directory, META-INF/reportPackage.json (documentType https://xbrl.org/report-package/2023/xbri for an Inline XBRL report, …/xbr for a non-inline one; .xbri/.xbr must match — PKG-010) and the report under reports/:

• a report file directly in reports/ is one report;
• a multi-document Inline XBRL report (an Inline XBRL Document Set) goes in a subdirectory: reports/<report name>/part1.xhtml, part2.xhtml, … — all the HTML documents of that directory form one report; contexts, units and ix:continuation elements may sit in any document of the set (ids are unique across the set, XBRL-008), ix:exclude content is not part of a fact;
• the filer's extension schema and linkbases sit next to the report;
• one filing is one report: a package with more than one report (for example two documents directly in reports/, or an inline report and an XBRL 2.1 instance) is refused (PKG-009) — the platform never picks one.

Untrusted-upload limits (XII guidance on safe handling of report packages; configurable):

Nothing is extracted to disk; XML is parsed without network access.

Naming (FRA-121, warning): <entity id>-<period end>-<reference>, e.g. FRA-LIC-0001-2025-12-31-annual.xbri; the same stem for .xhtml, .xbrl, .json.

16. Submission and the test-filing service

1. Test filing — POST /api/v1/xbrl/test-filing (OAuth scope filing:submit, sandbox and production credentials): send the report as multipart/form-data (file) or JSON (file_name, content_base64), optionally template_code (when the report references no template entry point) and fiscal_year. The platform runs exactly the validation of a submission and returns the validation report — nothing is filed (filed: false). The response (XbrlTestFilingResult in the OpenAPI document at /api/v1/openapi.json) holds validation: valid, status (passed/warnings/failed), summary, layers[] and findings[] (rule_id, layer, severity, message.ar, message.en, concept, context, period, arelle_code, document…) — the rule ids of the rules file.
2. Submission — POST /api/v1/filings/submit (encrypted envelope) or the portal upload. A refused report returns 422 xbrl_validation_failed with the same validation report.
3. Review — the FRA reviewer sees the stored validation of the filed report next to the published document's checks (section 5.5).

17. Conformance

• FRA conformance suite (tests/conformance/xbrl, index.json): good sample filings and at least one bad sample for every rule of the rule book (section 5 — all 69 ids; a test fails the build when a rule has none), run through the intake by php artisan fra:xbrl:conformance (--arelle to add Arelle, --only=B-PKG-*), which writes a JSON results report and fails when a sample does not produce exactly the expected rule ids. Samples for the business rules applied to the published document (FRA-001…FRA-006, FRA-W001) run those rules on the sample's facts ("stage": "published"); the two Arelle-only rules (XBRL-100, XBRL-101) have samples that are checked when Arelle runs and are reported as skipped otherwise. CI runs the native suite on every change and the whole suite (good and bad samples) again with Arelle.
• XII conformance suites: php artisan fra:xbrl:xii-conformance runs Arelle against the XBRL International suites found in XBRL_XII_CONFORMANCE_DIR and stores the per-variation results (docs/xbrl/CONFORMANCE.md explains how to download them; they are not committed).