Malaysia's stamp duty law is unambiguous: a duty stamp is only valid if you can prove when the document was signed. Not whether it was signed. When . That means the timestamp has to be logged, verifiable, and survive export as a PDF—because LHDN will not accept a screenshot of your e-signature platform's dashboard. Most e-signature platforms log signing timestamps by default. The problem is export. Many platforms strip the audit trail when you download the PDF, or bury it in metadata that LHDN's system does not read. Others log the timestamp but make it so cryptic that an auditor cannot verify it without calling the vendor's support line. We tested three categories of e-signature tools to see which audit trails actually hold up under LHDN scrutiny: enterprise platforms (DocuSign), native APIs you can build with, and integrated solutions like Orin. Here's what passes and what fails. Why LHDN cares about audit trails, not just signatures Stamp duty in Malaysia is calculated based on when a document is executed—not when it is dated. A sales and purchase agreement signed on 2 January incurs duty at January's rate. If signed on 2 February, you owe duty at February's rate. The difference can be thousands of ringgit. LHDN's position is straightforward: if you cannot prove the exact moment the document was signed, they will assess duty at the rate that favors the government. So the audit trail is not a nice-to-have; it is the only proof that holds up in a challenge. An audit trail in this context means: A timestamp showing when each party signed (not just the date, but hour and minute). The signer's identity (email or registered user ID, not just a name). A record that the PDF itself has not been modified after signing. All of this embedded in or attached to the PDF itself, not hidden in a backend database. Most platforms log this. Very few export it in a way that survives transmission to LHDN's MyInvois and e-invoice gateway systems, which have strict XML schema validation. DocuSign: Audit trail logs well, but certification adds friction DocuSign logs a complete audit trail for every signing session. Each signature capture includes a timestamp to the second, signer IP address, authentication method, and a hash of the document state at signing. That data gets embedded in the PDF's metadata and also stored in DocuSign's backend. The catch: LHDN does not automatically read DocuSign's proprietary metadata fields. The audit trail is there, but a human auditor has to know to request the Certificate of Completion report from DocuSign separately. The PDF alone will not satisfy a cursory LHDN review. For individual contracts and agreements, this is manageable. You download the signed PDF, then request the audit report from DocuSign's dashboard, print it, and attach it to your stamp duty application. Most LHDN officers will accept this. For high-volume invoicing or automated document workflows, this two-step process breaks down. If you are signing 500 contracts a month, manually pulling audit reports is not viable. And if your workflow integrates with an accounting system (like Xero or Orin's invoicing module ), DocuSign's metadata does not flow through—only the signed PDF does. DocuSign verdict: Audit trail exists and is strong. But it is not audit-safe for high-volume or integrated workflows without manual intervention at scale. Native APIs and webhook-based signing: The integration trap Many teams try to build e-signature workflows using native APIs from providers like AWS, or webhook-based signing from services like HelloSign (now Dropbox Sign) or SignNow. The appeal is obvious: you control the data flow, you own the integration, you can embed signing directly into your CRM or invoicing system. The audit trail problem is subtle. These platforms do log timestamps. But when you retrieve the signed document via API and insert it into your CRM or accounting system, the metadata context is often lost. The PDF comes back with the signature intact and a timestamp field, but that field is not always validated or certified in a way that LHDN's systems can read. Even worse: if your integration chains multiple systems (CRM → invoicing → tax gateway), the document passes through layers of export and re-import. Each layer risks corruption of the original timestamp metadata. One team we spoke with built a workflow using Dropbox Sign's API, integrated it into their Odoo ERP, and submitted signed contracts to LHDN via MyInvois. The signed PDFs had valid signatures and timestamps in Dropbox's backend. But when MyInvois ingested them, it rejected them because the timestamp was not in the expected XML format. LHDN then required them to resubmit with a separate audit certificate—which Dropbox Sign did provide, but only after a support ticket. Native API verdict: Timestamps are logged but easily lost in integration chains. Requires careful mapping and testing before high-volume use. Not suitable for automated invoice workflows without a com