Tanzania's Revenue Authority requires that a sale be fiscalised — passed through an EFD or virtual fiscal device, assigned a receipt number and verification code, and reproduced in a customer-readable form — before it is a valid tax document. Dynamics 365 Business Central posts a clean sales invoice, applies your VAT posting setup and files it in the posted document archive, and then stops. There is no fiscal device client in the base application, no TRA tax-code concept alongside your VAT posting groups, and no notion of a document being posted-but-not-yet-accepted. Finance teams close that gap by hand: post in Business Central, re-key into a standalone fiscal device or supplier portal, and reconcile two sets of numbers at month end. Every re-key is a mismatch risk, and every mismatch is an audit exposure.\n\nECOSIRE builds a Business Central AL extension that closes the loop inside the system where the invoice already lives. A codeunit-based VFD client handles authentication, request signing and HTTPS transport to the fiscal device or gateway your business uses. Table extensions on the sales header and posted sales invoice carry the fiscalisation state — pending, submitted, accepted, rejected — plus the returned receipt number, verification code and timestamp. Page extensions surface that state where your AR clerk is already working, with a fiscal factbox and a resubmit action rather than a separate screen. Event subscribers on the posting codeunits enqueue the document, and a job queue entry drains the queue asynchronously so a slow or unavailable device never blocks a posting run.\n\nTax mapping is derived from your existing master data rather than duplicated. We extend VAT Posting Setup, Item and Item Category with TRA tax-code fields, validate the mapping at posting time, and fail loudly with a clear message when a line has no mapped code — because a silent default is how the wrong rate reaches the authority. One posting produces both outputs the requirement asks for: the machine payload sent to the device, and the human-readable fiscal receipt, rendered as a Business Central report layout carrying the receipt number and verification QR so the customer copy and the fiscal record can never diverge.\n\nRejections are treated as a workflow, not a log line. A rejected submission lands in a fiscalisation error queue with the device's own reason code, the exact payload sent and a correction action that routes to a credit note or a corrected resubmission depending on whether the document was already accepted. Every attempt — accepted or not — is written to an immutable fiscal record table that no user role can edit, giving your auditors a defensible trail from the posted entry back to the TRA response. Where you need the data outside Business Central, we expose it through API pages on REST API v2.0 / OData v4 so Power BI, Power Automate or a Dataverse-connected app can read fiscalisation status without a database extract.\n\nThis is build-to-order, not an AppSource download. We start with a short scoping call to confirm your Business Central version and deployment model, which fiscal device or gateway you are contracted with, how your invoicing, POS and credit-note flows actually run, and which permission sets and approval steps must be respected. From confirmed scope, typical delivery is two to four weeks: we build against your version, install and configure on your sandbox, run UAT with your own documents, then publish to production with a rollback plan. You receive the AL source and the git repository, so the extension stays yours to maintain, extend or hand to another partner.