MAFG_Reporting_Overview

1.

MANDATORY ASP FILE GENERATOR
Reporting
What the tool reports, who receives it, and when.
UAE e-invoicing · Orient Insurance PJSC

2.

Two kinds of reporting
Operational reports read on screen; distributed reports sent to people.
Operational
Distributed
Read inside the tool. Nothing leaves the machine.
Sent to a recipient after a document is produced.
Overview
Reconciliation and daily run ledger
Client & CRM
Generated items
Every document produced, with status
Documents register
The full record, exportable
The client, broker and KAM
MBR storage
The client's archive mailbox
ASP reconciliation
Sent against issued and rejected
Credit control
Audit log
Who did what, and when
The credit control team

3.

The three distributed reports
The difference between them is the recipient and the trigger.
Client & CRM breakdown
MBR storage
Credit control
Per combined document
Per combined document
Three periodic reports
Goes to
Client, broker
Goes to
Client's MBR mailbox
Goes to
Credit control
Copied
KAM / CRM
Copied
Nobody
Copied
Nobody
Trigger
ASP confirms issuance
Trigger
File sent to the ASP
Trigger
Daily / weekly / monthly
Level
Per client
The components of one invoice, at the level of
detail that client is configured for.
Level
Per client
The same breakdown, filed for archive. Goes
earlier than the client copy.
Level
Whole portfolio
Transactions, ASP outcomes, and combined
billing detail.

4.

Credit control: three reports
Each has its own frequency and its own recipient.
3.1
Transactions
Daily default
Everything sent to the ASP in the period, issued or not.
3.2
ASP transactions
Daily default
What the ASP issued or rejected, with the reason for each rejection.
3.3
Combined billing
Weekly default
Every L&D client on combined billing, with the components inside each document.
Every title carries its period: “Daily transactions — 14 January 2027”, “Monthly transactions — 1 January to 31 January 2027”. A report headed only “Transactions” is
ambiguous the moment it is filed.

5.

What goes in a report
Four fields are always present. The rest are chosen per report.
Always included
Chosen per report
Combined invoice / credit note number
Business group ID and name
Preceding invoice and its date
Individual component amounts
Group ID, name and entity
ASP status, batch and issue date
Original OPUS invoice and credit note numbers
Product and sub-product line
Credit terms and payment method
OPUS invoice date
Net, VAT and total per component
Two reports never see all of it
MBR is an archive filed against a client the mailbox already identifies, so it omits entity, client details and payment method.
The client breakdown says “Invoice date”, not “OPUS invoice date” — OPUS is an internal system name and means nothing to a client.

6.

PDF, and where it stops
Page size is chosen from the column count, not fixed.
REPORT
COLUM NS
PRINTS AS
Billing breakdown — client
8
A4 portrait
MBR storage
7
A4 portrait
ASP transactions
7
A4 portrait
Transactions
8
A4 portrait
MBR — all fields
18
A3 landscape
Transactions — all fields
20
A3 landscape
Combined billing — all fields
21
A3 landscape
Wide reports are working files, not documents. An 18–21 column table cannot be read on A4. Credit control will filter and sort these, which a PDF obstructs —
so those belong in Excel or CSV. PDF is right for the client and MBR reports, which are 7–8 columns and print cleanly.

7.

What the tool cannot do yet
Worth saying plainly before anyone demonstrates this.
Nothing sends itself
Samples are illustrations
The tool cannot know when the ASP confirmed issuance, and a file on one PC
cannot run on a schedule. The settings define what Power Automate will do.
The sample reports show layout with invented figures. They are not yet
generated from your data.
Excel and CSV are not built
Ad-hoc reports are not built
Agreed as the right format for the wide credit control reports. Still to do.
A user-defined report across groups, brokers and documents. Still to do.