0. Terms used in this guide

A short glossary so every reader starts from the same baseline. The rest of the document uses these terms without re-explaining them.

1. Overview — what TrustBill delivers for Fusion

Oracle Fusion Cloud ERP has no native UAE FTA access point. It does not emit PINT-AE XML, cannot speak Peppol AS4, and cannot talk directly to the FTA's e-invoicing gateway. TrustBill sits between Fusion and the FTA: we take sales-side invoice data out of Fusion, transform it into the UAE PINT-AE UBL profile, validate it against the FTA's business rules, submit it through an FTA-accredited ASP over Peppol AS4, and send the signed, delivered document back to Fusion as a status update plus the official PDF/A-3 copy.

Your Fusion footprint stays as it is. We do not customise Fusion standard screens, we do not ask you to switch your invoice numbering strategy, we do not require a managed-services engagement from Oracle, and we do not install anything inside your Fusion tenancy. All transformation and FTA logic lives in TrustBill.

2. Three integration options — side-by-side comparison

Not every Fusion customer needs the same depth of integration. We offer three options at three price points. Pick the one that matches your invoice volume, your IT change-management posture, and whether you need the FTA UUID back on the printed invoice in real time.

All three options use the same TrustBill PINT-AE pipeline and the same FTA-accredited ASP. Only the Fusion-side trigger and the write-back path differ. Starting on Option 1 and moving up later is a configuration change, not a rebuild.

Section §4 breaks down the scope and effort for each option in full detail so you (or your Oracle MSP) can plan the internal work before signing. Pricing is maintained separately on the ERP integration pricing page — this document stays technical.

3. Advanced integration architecture

The advanced path is three systems in sequence. Fusion is the system of record, Oracle Integration Cloud (OIC) is the orchestrator inside your perimeter, and TrustBill is the UAE compliance plane that terminates at the accredited ASP and the FTA.

┌─────────────────────┐    1. Business event        ┌──────────────────┐
│  Oracle Fusion ERP  │ ───────────────────────────▶│   Oracle         │
│  (AR, Receivables)  │   (Invoice Completed)       │   Integration    │
└─────────────────────┘                             │   Cloud (OIC)    │
         ▲                                          └────────┬─────────┘
         │ 6. Status + UUID written back                     │
         │    (custom DFF or OIC callback)                   │ 2. Enrich + POST
         │                                                   ▼
┌────────┴─────────┐                               ┌──────────────────┐
│   OIC inbound    │  5. Signed webhook (HMAC)     │   TrustBill      │
│   webhook        │ ◀──────────────────────────── │   Partner API    │
│   (your tenant)  │                               │  api.trustbill.ae│
└──────────────────┘                               └────────┬─────────┘
                                                            │ 3. PINT-AE
                                                            │    transform
                                                            │    + FTA rules
                                                            ▼
                                                   ┌──────────────────┐
                                                   │ FTA-accredited   │
                                                   │ ASP (Peppol AS4) │
                                                   └────────┬─────────┘
                                                            │ 4. Clear
                                                            ▼
                                                   ┌──────────────────┐
                                                   │  UAE FTA         │
                                                   │  e-invoicing     │
                                                   │  gateway         │
                                                   └──────────────────┘

1. Fusion emits the standard AR Transaction Complete business event (subscribed to through the Oracle ERP Cloud Adapter in OIC) when a sales invoice is completed and tax has been calculated.
2. An OIC integration subscribes to the event, enriches it with buyer master data, exchange rate and legal entity details, and POSTs the resulting JSON document to `https://api.trustbill.ae/v1/partner/invoices` with an `Idempotency-Key`.
3. TrustBill validates the payload, transforms it to PINT-AE UBL, applies the FTA UAE profile rules, signs the document, and submits it to our FTA-accredited ASP over Peppol AS4.
4. The ASP relays the invoice to the FTA. The FTA returns a delivery acknowledgement and the official invoice UUID.
5. TrustBill sends an HMAC-SHA256-signed `invoice.status_changed` webhook to the inbound OIC endpoint you register, carrying the FTA UUID, the delivery timestamp, and a URL to the PDF/A-3 copy and the signed UBL.
6. The OIC flow verifies the signature, parses the body, and writes the UUID and status back to the Fusion invoice (standard integration: two Descriptive Flexfields on the AR Transactions header).

4. Scope + effort — per option

This section is what your Oracle team and ours will refer to during the Statement of Work. For each option we list exactly what TrustBill delivers, what your Fusion team delivers, how many person-days each side needs, and the all-in activation fee. Add your internal day-rate to the 'your effort' row and you have your total cost for the option.

— — — — — — — — — — — — — — — — — — — — — — — — — — —

— — — — — — — — — — — — — — — — — — — — — — — — — — —

— — — — — — — — — — — — — — — — — — — — — — — — — — —

5. Prerequisites checklist

Have the following ready before kick-off. Anything missing on this list typically shifts the go-live date by one week per item.

1. Oracle Fusion Cloud ERP: supported releases are 24A and later. 23D is supported until July 2026.
2. Oracle Integration Cloud (OIC Gen 2 or OIC Gen 3) — Standard edition is enough.
3. A named enterprise architect from your side, empowered to approve API design decisions in a single meeting.
4. A named Fusion functional lead for AR + Tax.
5. A named OIC developer who can deploy to DEV, UAT and PROD under your release train.
6. A signed Statement of Work scoping AR / sales invoices only.
7. UAE TRN per legal entity in scope, matched to Fusion BUs.
8. DEV, UAT and PROD environments all accessible from OIC (not blocked by SSO-only rules).
9. Firewall change tickets raised for outbound to `api.trustbill.ae` and inbound from the TrustBill egress CIDR we provide.
10. A business sign-off from your Finance / Tax director that AR invoices can be transmitted to the FTA from go-live.

6. Authentication model

The Partner API uses a two-layer authentication scheme. The first layer is the standard partner credential, which proves to TrustBill that the caller is a known ERP integrator. The second layer is a per-SME secret, which proves that this specific push belongs to the specific legal entity whose invoice is being issued. Both must be present on every write.

7. Payload — what OIC sends to TrustBill

A minimal AR tax invoice payload looks like this. The full schema is published at `https://api.trustbill.ae/v1/partner/openapi.json` and covers simplified invoices, commercial invoices, credit notes and debit notes under the same shape.

POST /v1/partner/invoices HTTP/1.1
Host: api.trustbill.ae
Content-Type: application/json
X-API-Key: tbp_live_7f3c…
X-API-Secret: tbs_live_••••••••
x-erp-partner-secret: ers_live_••••••••
Idempotency-Key: fusion-inv-2026-10-16-00042

{
  "documentType": "tax_invoice",
  "externalRef": "INV-2026-00042",
  "issueDate": "2026-10-16",
  "dueDate":   "2026-11-15",
  "currency": "AED",
  "seller": {
    "trn": "100123456700003",
    "legalName": "Acme Trading L.L.C",
    "address": { "country": "AE", "emirate": "Dubai", "line1": "Office 902, Boulevard Plaza T1" }
  },
  "buyer": {
    "trn": "100987654300003",
    "legalName": "Beta Distribution F.Z.E",
    "address": { "country": "AE", "emirate": "Sharjah", "line1": "SAIF Zone, Q1-05" }
  },
  "lines": [
    {
      "sku": "ACME-SKU-001",
      "description": "Industrial pump, model X9",
      "quantity": 2,
      "unitPrice": 1500.00,
      "taxCategory": "S",
      "taxRate": 5
    }
  ],
  "totals": {
    "netAmount":   3000.00,
    "taxAmount":    150.00,
    "grossAmount": 3150.00
  },
  "indicators": {
    "freeZone":     false,
    "reverseCharge": false,
    "marginScheme":  false,
    "export":        false
  }
}

On success you receive a `202 Accepted` with an envelope containing the TrustBill invoice ID, the normalised document hash and `status: "queued"`. The webhook is the authoritative delivery channel for the final FTA clearance.

8. Fusion ↔ TrustBill field mapping

The OIC flow is where this mapping lives. Use the table as the acceptance criterion for the OIC build — once every row is wired, you are 95% of the way through functional UAT.

9. Status webhooks back from TrustBill

When an invoice reaches a terminal state (`delivered` or `rejected`), TrustBill POSTs a single `invoice.status_changed` event to the webhook URL you registered in the TrustBill partner portal. Deliveries are durable, signed, and retried on a fixed schedule.

POST /your-oic-webhook-url HTTP/1.1
Content-Type: application/json
X-Webhook-Timestamp: 1760606062
X-Webhook-Signature: t=1760606062,v1=4e9c3d…hex…

{
  "event": "invoice.status_changed",
  "deliveredAt": "2026-10-16T09:14:22Z",
  "payload": {
    "event": "invoice.status_changed",
    "invoiceId":   "inv_01HZ…",
    "externalRef": "INV-2026-00042",
    "status":      "delivered",
    "ftaUuid":     "f1b8c7e2-9d4a-4b11-9c38-7c7a3a9c0e8b",
    "deliveredAt": "2026-10-16T09:14:19Z",
    "assets": {
      "signedUbl": "https://api.trustbill.ae/…/signed.xml",
      "pdfA3":     "https://api.trustbill.ae/…/invoice.pdf"
    }
  }
}

1. `status: "delivered"` — the invoice has been delivered to the FTA; `ftaUuid` is the official UUID to store on the Fusion invoice and to print on the PDF.
2. `status: "rejected"` — the FTA (or pre-submit validation) rejected it. The payload carries the error code and a human-readable reason. The invoice stays as `rejected` in TrustBill; a corrected re-submission is a new logical invoice (same `externalRef` with an incremented sub-sequence) or a credit note.

Signature verification is mandatory. Your OIC inbound flow must do these four checks before trusting the payload:

1. Read `X-Webhook-Timestamp` and parse the `v1=<hex>` value out of `X-Webhook-Signature`.
2. Reject if `|now − t| > 300 seconds` — this blocks replay attacks.
3. Compute `hmac_sha256(webhook_secret, `${t}.${raw_body}`)` and constant-time compare to `v1`.
4. Only after both checks pass, parse the JSON body and update the Fusion AR invoice DFFs.

Retry schedule on any non-2xx or transport failure: 30s → 2m → 10m → 30m → 1h → 3h. After the 6th attempt the delivery is marked `exhausted`. The invoice itself in TrustBill is unaffected: you can `GET /v1/partner/invoices/:id` at any time or fire a fresh attempt with `POST /v1/partner/invoices/:id/replay-webhook`.

10. Error handling

All error responses are RFC 7807 problem documents (`application/problem+json`). Your OIC flow should branch on the stable `type` slug — not on the human `title` or the HTTP status alone. These are the error types you will actually see from the Partner API:

11. Environments and cut-over plan

A healthy Fusion ↔ TrustBill rollout runs through four environments, matched on both sides. Each move forward requires a signed sign-off from the equivalent-tier owner.

1. Week 1 — Kick-off, SOW signed, DFFs deployed to DEV/TEST/UAT, Partner credentials issued.
2. Week 2 — OIC flow built, 10 synthetic invoices across all tax categories in sandbox.
3. Week 3 — Historical sync of the previous 90 days via `POST /v1/partner/invoices/bulk` (dry-run against submission-sandbox).
4. Week 4 — UAT with real business owners, 50-invoice daily cadence in submission-sandbox.
5. Week 5 — PROD cut-over at a quiet window (we recommend Thursday 20:00 GST). First 48h at 50% invoice routing with manual spot checks.
6. Weeks 6–10 — Hypercare at 100% routing; weekly ops review; close-out of the SOW on week 10.