Skip to main content
Trust › Compliance Posture

Built to Withstand Scrutiny

CoralLedger Comply is designed against primary legislation, mathematically deterministic, and built around a hash-chain audit trail. Cryptographic sealing of every sign-off is the platform’s design target and is under final verification ahead of beta launch.

Designed Against Primary Legislation

Built On Statute, Pending Independent Review

CoralLedger Comply’s VAT calculation engine, attestation workflow, and audit trail were designed against the primary legislation — the Value Added Tax Act 2014, the Value Added Tax (Amendment) Act 2026, and DIR Form 32a v2.4 — with internal regulatory analysis cross-referencing each calculation to its statutory provision.

An independent third-party regulatory review is being arranged. This page will name the reviewing firm and publish its findings on completion.

  • VAT calculation logic is anchored to the VAT Act 2014, the VAT (Amendment) Act 2026, and DIR Form 32a v2.4

  • Rate classifications cover standard-rated, reduced-rate, zero-rated, and exempt supply categories

  • Apportionment methodology implements the partial-deduction rules in Schedule 3

  • Attestation workflow is built around §32 signatory requirements

  • Audit trail uses a hash-chain architecture

Calculation Determinism

107 Golden Hashes

Every VAT computation in CoralLedger Comply is validated against 107 canonical expected outputs in the golden-hash determinism suite. For any given set of inputs the system always produces the same result — down to the cent. Calculations cannot drift silently.

107 Canonical Test Cases

Each golden hash in the golden-hash determinism suite covers a distinct input scenario: standard-rated supplies, zero-rated exports, exempt supplies, mixed-rate apportionment, food-store licence exemptions, and rate-spanning continuous supplies.

Deterministic Output

For every set of inputs, CoralLedger Comply produces byte-for-byte identical Output Tax, Input Tax, and apportionment fractions — run the same return today or in six months, the figures never drift.

Regression-Locked Calculations

Any code change that would alter the output for an existing test case breaks the golden-hash suite and is blocked from reaching production. The calculation engine cannot silently regress.

DIR Rate Schedule Alignment

All 107 cases are mapped to specific provisions of the VAT Act 2014 and the April 2026 DIR rate schedule. Each hash is annotated with the statutory reference it validates.

What "regression-locked" means in practice

Before any code change reaches production, the full golden-hash determinism suite runs in CI. If a change would alter the output for even one of the 107 cases — even a rounding difference of a single cent — the build is rejected and the change is reviewed before it can proceed. The calculation engine is frozen against the Act; only a statutory amendment can unlock it.

Audit Trail Vocabulary

What the Audit Trail Terms Mean

CoralLedger Comply uses precise, legally meaningful terminology in every audit record. Understanding these terms helps practitioners, auditors, and business owners interpret the evidence package confidently.

Audit Entry

A single, timestamped record that captures an action performed on a VAT return or transaction — who did it, what changed, and when. Every audit entry is individually hashed.

SHA-256 Hash

A cryptographic fingerprint generated from an audit entry's content. If even one character in the entry is altered after the fact, the hash changes. That is why the platform's hash-chain design is intended to detect tampering once verification is complete.

Chain Link

Each audit entry is designed to include the hash of the preceding entry, forming an unbroken chain. Deleting or reordering entries is intended to sever the chain and be detectable during verification.

Tamper Event

A detected break in the hash chain. Chain-verification observability is under final verification; when active, tamper events surface in the Audit Defense Dashboard with the exact entry where integrity was lost and the downstream records affected.

Chain Integrity Status

An integrity indicator used to confirm whether audit entries from creation to present remain unaltered. Continuous production verification is under final verification before this status is advertised as live evidence.

Immutable Record

An audit entry sealed into the platform's hash-chain design. Once production signing and chain verification are fully confirmed, no user — including platform administrators — should be able to modify a sealed entry without detection.

BICA Verification

Practitioner Attestation You Can Stand Behind

The Bahamas Institute of Chartered Accountants (BICA) licences the practitioners who attest VAT returns on behalf of clients. CoralLedger Comply enforces a four-step verification gate before a practitioner's identity is ever stamped on a return.

1

Licence Submission

The practitioner enters their BICA licence number during onboarding. CoralLedger Comply records the number against the practitioner profile.

2

Engagement Letter Requirement

An active engagement letter between the practitioner and the client entity must be on file before the prefill pathway activates. Inactive or expired engagements are excluded by rule.

3

Dual-Condition Gate

Both an active client assignment AND an active attestation profile must be present. Either condition missing locks the prefill — no exceptions. The system cannot be overridden.

4

Prefill Attribution

When both conditions pass, Comply stamps the return with the practitioner's verified name and BICA licence number. Workload assignees who are not the practitioner of record never receive the prefill.

The dual-condition gate cannot be bypassed. Active client assignment AND active attestation profile must both be present. A workload assignee who is not the named practitioner of record never receives the prefill — by architecture, not by policy.

Per-Attestation Records

Cryptographic Sign-Off Sealing Is Under Final Verification

Every sign-off will be cryptographically sealed once production signing is enabled. The signing pipeline and chain verification are under final verification, while row-level deletion immutability remains under engineering review for Addendum 1.

One Dedicated Record Per Return

When a VAT return is attested, CoralLedger Comply creates a separate attestation record distinct from the underlying transaction log. Engineering verification of the immutable-storage implementation is tracked in Addendum 1 before any absolute claim is made.

Timestamp and Signatory Capture

Each attestation record captures the UTC timestamp, the identity of the signatory, the signatory's declared authority (e.g. director, BICA practitioner), and the filing period covered.

Linked to the Return Snapshot

The attestation record references the exact state of the return at the moment of signing — if the underlying figures are ever queried, the system can reproduce the return as it appeared when attested.

Included in Every Audit Export

Attestation records are exported as a structured component of the Audit Defense Package — auditors receive both the return data and the evidentiary record needed to validate signatory confirmation once production signing verification is complete.

Designed (AA-049): Attestation records are implemented as a separate tenant-scoped entity. Body-text content is designed to be tamper-evident via SHA-256 hash; row-level deletion immutability remains under engineering verification.

Evidence — body-text tamper evidence: The Attestation entity in the Comply application's domain layer is a separate tenant-scoped entity (distinct from the transaction log) via a required BusinessId field. Its body text carries a SHA-256 TextVersionHash over BodyId|Version|BodyText, computed at creation and recomputable on read. Production signing for every attestation remains under final verification; implementation references will be cited in the public engineering addendum.

Evidence — pending Addendum 1: Row-level deletion immutability and any inter-record hash-chain claim require additional engineering verification and will be cited in Addendum 1 alongside the attestation-workflow review.

Carve-outs

Supplies That Require Additional Review

Two supply types require a manual verification step before a practitioner can attest with confidence. CoralLedger Comply flags both for practitioner review.

Real estate deposits

Deposits received before a rate-change date may span two different VAT periods and rates. CoralLedger Comply flags these deposits for manual review. The practitioner must determine the correct time-of-supply rule before attesting.

Rate-spanning continuous supplies

A continuous supply that straddles a rate-change date (e.g. a retainer contract that began before April 1, 2026) requires apportionment workings. Comply calculates the apportionment, but the practitioner must verify the contract start date and confirm the split before signing.

Flagging supports practitioner review — resolution is your call. CoralLedger Comply surfaces every carve-out item during return generation so nothing is overlooked. The practitioner confirms each item before the prefill releases. If supply type is unclear, consult a registered VAT advisor or the Department of Inland Revenue before attesting.

Frequently Asked Questions

What is a "compliance posture"?

A compliance posture is the sum of technical, procedural, and evidential controls a system puts in place to ensure every calculation, attestation, and record meets the requirements of the relevant law. CoralLedger Comply's compliance posture is built on four pillars: deterministic calculation, hash-chain audit trails by design, verified BICA attestation, and per-return sign-off records under final verification.

What are the 107 golden hashes?

107 golden hashes are the canonical expected outputs for 107 representative VAT scenarios in the golden-hash determinism suite — covering all four rate categories, the principal supply types, and the high-value edge cases identified during regulatory review. The calculation engine is regression-locked against these outputs: any code change that would alter the calculated result for an existing case fails the CI gate and cannot be merged to production.

Can a user or administrator alter an audit record?

By design, no sealed audit entry should be modifiable by any user — including platform administrators — without changing the entry's hash and breaking the chain. Production signing and chain verification are under final verification, so this page describes the intended control rather than a completed production attestation.

How does BICA licence verification work?

Practitioners enter their BICA licence number during onboarding. The number is stored against the practitioner profile and is stamped onto every return where the prefill pathway activates. Activation requires both an active client assignment and an active attestation profile — neither condition can be bypassed.

Are carve-out supplies excluded from the prefill?

Yes. When CoralLedger Comply detects a real estate deposit straddling a rate-change date or a rate-spanning continuous supply, it withholds the attestation prefill and surfaces a review prompt. The practitioner must confirm each flagged item before the prefill is released.

Has the platform been independently reviewed?

CoralLedger Comply was developed against the primary legislation — the Value Added Tax Act 2014, the Value Added Tax (Amendment) Act 2026, and DIR Form 32a v2.4 — with internal regulatory analysis cross-referencing each calculation to its statutory provision. An independent third-party regulatory review is being arranged; this page will name the reviewing firm and publish its findings on completion.

Compliance You Can Demonstrate

Independent review, deterministic calculations, audit-trail integrity by design, and verified BICA attestation — all in one platform. Free during open beta.