What real-time e-invoicing means
Real-time e-invoicing brings tax-authority reporting or clearance closer to the moment an invoice is issued. Structured transaction data is transmitted and acknowledged alongside the document a customer reads. The operational question becomes: what must happen when we issue this invoice?
Authorities use different data models and clearance or reporting approaches. Check the current requirements governing your transactions before choosing a process. The global examples here explain the category; Fiskl One serves FBR Digital Invoicing in Pakistan.
From periodic reporting to transaction controls
In a periodic reporting model, a business issues invoices, records them in its books and prepares reporting later. The reporting period provides a point at which teams reconcile the transaction records. The invoice still needs accurate information, but tax reporting is a subsequent activity rather than an interaction embedded in each issuing workflow.
Continuous transaction controls, often shortened to CTC, move clearance or reporting to the transaction. The system needs invoice information in a structured form at the point it is reported or cleared. Identity, item classification, rates and amounts become integration inputs. Data that once required later reconciliation may need review before the invoice can complete its reporting path.
The practical effect is a change in responsibility and timing. Finance teams still decide what the invoice should contain. IT teams help maintain the flow of that data and the handling of responses. The two teams need to agree on the meaning of a successful acknowledgement, the handling of rejection and the evidence retained with each invoice. A periodic reporting habit alone does not answer those questions.
Clearance and reporting models
Two conceptual approaches
In a clearance model, the authority’s processing or acknowledgement sits within the issuing path. Ask where its response is required and which record establishes that the clearance step has completed.
In a reporting model, the business transmits invoice data to the authority for transaction reporting and later review. Preserve the submitted data and response, with a clear distinction between internal review, submission and acknowledgement.
The diagram compares periodic reporting with a conceptual real-time flow. The table distinguishes clearance from reporting. Use both to identify the steps your team must complete and the evidence it must retain.
Periodic reporting
After the transaction- 01Invoice
- 02Books
- 03Monthly return
- 04Review and audit later
The invoice is recorded first. Tax reporting and review follow later.
Real-time reporting
At the transaction- 01Invoice
- 02Validated
- 03Reported to tax authority
- 04Invoice number acknowledged
In real-time regimes, reporting and acknowledgement happen as the invoice is issued.
| Question | Clearance | Reporting |
|---|---|---|
| Who acts | Business submits data; authority processes it in the issuing path. | Business issues and reports invoice data; authority can review it later. |
| When the invoice is valid | The required clearance step is part of issue; the regime defines its legal effect. | Issue and reporting are distinct steps; the regime defines validity and timing. |
| What the business keeps | Submitted invoice data and the clearance response or identifier. | Issued invoice data and the reporting acknowledgement for later review. |
The data and evidence in common
Structured data makes invoice fields available to software rather than leaving them only in a visual document. Seller and buyer identity, items, quantities and amounts can be transmitted as individual values. For a finance team, this means the quality of the source fields matters. A PDF that looks plausible can still be based on a field combination that needs correction.
Unique invoice identifiers make it possible to connect a transaction record to its acknowledgement. In Fiskl One, a successful FBR post returns an invoice number that is stored with the invoice. The team can distinguish a prepared invoice from a posted one by examining the saved state and number, rather than assuming that generating a document completed the reporting step.
QR codes are another way of carrying invoice information into a readable document. Their contents and role depend on the applicable system. Fiskl One’s PDF QR encodes the FBR-issued invoice number. That is a specific product behaviour. Keep the number with the saved invoice record.
Tax-authority acknowledgement is an event the workflow must interpret. Ask what data is returned, how it is associated with the invoice and what the user sees when the attempt fails. A usable process makes the current state and next action visible. It also keeps the distinction between a local record, a submission attempt and a successful authority response clear.
Examples of the global category
The regimes below illustrate the spread of transaction-level invoicing controls. Use each example as a starting point for reading the relevant authority’s material. Fields, acknowledgement and the reporting path can differ between systems.
Evaluate a product against the authority workflow it actually supports. Rupee Craft currently serves FBR Digital Invoicing through Fiskl One. For a different workflow, begin the discussion with your requirements.
What changes for finance teams
Finance teams need to review the invoice as structured data. Confirm the counterparty identity, supply context and rate, then reconcile the amounts. Establish who owns the decision to post and what that person checks first. A process that depends on the last person in the chain noticing every error is harder to explain than one with named review responsibilities.
Recurring supplies deserve reusable preparation rules and a documented tax decision. Reusable buyer profiles and live reference choices can help with entry, but they do not replace review. The team should understand when a saved value remains appropriate and when a changed supply or counterparty requires a new decision. Software displays the selected fields; responsibility for the transaction data remains with the business.
Agree on how to read failures. A validation error calls for review of the returned information and correction of the relevant fields. A posting attempt in progress calls for waiting for its result rather than issuing another request. A posted invoice is a retained record with its acknowledgement. These are different operational situations and should not be handled with the same generic instruction.
What changes for IT teams
IT teams need to understand the reporting path and its boundaries. In Fiskl One, the browser portal talks to the API, which handles authenticated records and calls the FBR integration service for validation and submission. The returned FBR invoice number is stored with the invoice. The architecture view distinguishes those responsibilities so a reviewer can trace how the record moves through the system.
Access controls and data handling belong in the evaluation alongside the reporting sequence. Ask how accounts are provisioned, which queries are scoped to the account and what administrators can see. Ask how monetary values are stored and what audit events exist. Specific answers are more useful than broad security adjectives because they describe behaviour your team can assess.
State handling is another integration concern. A provider should be able to explain what prevents concurrent or duplicate posting and how a failed attempt can be retried. The explanation needs to connect the visible user action to the saved invoice record and the response. A diagram is useful when it makes those relationships clearer; it should not stand in for the underlying rules.
Evaluate the workflow, not just the screen
Questions for a provider walkthrough
Begin with a representative invoice and the authority requirements you need to meet. Ask the provider to show preparation, reference choices, validation, submission and acknowledgement using that example. Include the fields that vary in your business. A walkthrough that only demonstrates a successful invoice can leave unanswered questions about review and failure handling.
Ask to see the stored outcome and the next action for each relevant state. Then review a failure path and the controls around retrying. Confirm what the PDF contains, which actions are locked after posting and what the audit history covers. Keep any claim about a certification, availability, integration or service level separate until the provider can substantiate it.
Use the checklist below to structure the discussion. It is a local review aid. Compare the answers with your operational needs and the current authority requirements. Record any unanswered question explicitly so the team can resolve it before treating a workflow as ready.
0 / 7 reviewed · local checklist
Selections reset when you leave this page.
Where Rupee Craft fits
Rupee Craft builds compliance infrastructure that connects invoice preparation to tax-authority reporting. Fiskl One puts this approach into practice for FBR Digital Invoicing: reusable profiles, 28 selectable scenarios, live reference lookups, validation before posting and a retained FBR invoice number. Posted invoices are locked, and their PDF includes a QR code encoding the number.
The how-it-works page explains the current architecture and invoice states. The scenario explorer provides the supported FBR descriptions. The security page describes existing access, storage and audit controls. Read those pages together to assess the scope of the product and the evidence your team can review after an invoice has been issued.
Book a demo to talk through your sectors, scenarios and monthly invoice volume. Rupee Craft is extending the same validation and reporting pipeline to more invoicing workflows; talk to us about your requirements. A useful discussion starts with the transaction, the authority’s requirements and the decisions your finance and IT teams need the workflow to support.
Confirm the applicable authority requirements before configuring your workflow.