Digital Signature & Document Numbering

25
March

For Implementation Team

Digital Signature & Document Numbering — Why It Differs from e-Saraban and How to Solve It with Incremental Save

"Why can't the ERP system change document numbers after signing?" — This question arises almost every time we implement an ERP system with Digital Signatures in organizations that previously used e-Saraban (electronic document management) systems. Users are accustomed to e-Saraban where you "sign first, then assign the number," and expect the ERP system to work the same way.

This article explains why it technically cannot work the same way, the difference between "Server Sign" in e-Saraban and "real Digital Signatures per Section 28 of the Electronic Transactions Act," and the solution that is correct both technically and legally.

Summary: e-Saraban systems use "Server Sign" (just stamping a signature image onto PDF), so documents can be modified after "signing." But real Digital Signatures per Section 28 use Cryptographic Hashing — changing even 1 character makes the signature invalid immediately. The solution is PDF Incremental Save, which appends the document number without modifying the previously signed content.

The Problem

In Thai government agency workflows, the document issuance process typically follows this pattern:

1 Create Document — Draft the letter, no document number yet

↓

2 Approver Signs — Department head / Director signs the document

↓

3 Assign Document Number + Date — Records unit registers, assigns number and date

In e-Saraban systems, this works because "signing" in e-Saraban is not a real Digital Signature — it's just stamping a signature image (Server Sign) onto the PDF, which means the document can still be modified after "signing."

But in ERP systems using real Digital Signatures per Section 28 of the Electronic Transactions Act, changing the document number or date after signing = modifying the document = signature becomes void.

The Problem: PDF is created with "Draft" number → Approver signs with Digital Signature → System changes number + date on Complete → All previous signatures become invalid

"Server Sign" in e-Saraban vs Real "Digital Signature" — What's the Difference?

This is the biggest source of misunderstanding:

Aspect	Server Sign (e-Saraban)	Real Digital Signature (Section 28)
Method	Stamps a signature image onto PDF	Uses Private Key to encrypt Hash of entire document
Modify after signing	Possible — no integrity check	Impossible — system detects immediately
Identity verification	Server login only (no PKI)	Certificate issued by trusted CA
Document integrity	Not guaranteed — anyone can edit	100% guaranteed — even 1 byte change detected
Standard	No unified standard	PAdES (ETSI EN 319 142), X.509, RFC 3161
Legal compliance	Does not meet Section 28	Fully compliant
In Adobe Acrobat	No Signature Panel / "None PKI"	Signature Panel + Certificate + Signer + Date

Simply put: "Server Sign" in e-Saraban is like sticking a signature sticker on paper — anyone can peel it off and change the content. But a real "Digital Signature" is like a Wax Seal on an envelope — you immediately know if someone has tampered with it.

The Solution: PDF Incremental Save + Organization Stamp

The PDF standard (ISO 32000) and PAdES (PDF Advanced Electronic Signatures) already define the correct method: Incremental Save — appending data to the end of the PDF without modifying existing content.

The Correct Flow

1 Create PDF — Complete content, document number = "DRAFT" or blank

↓

2 Approver 1 signs Digital Signature (Incremental Save #1)
→ Signature 1 covers: Content + "DRAFT"

↓

3 Approver 2 signs Digital Signature (Incremental Save #2)
→ Signature 2 covers: Content + "DRAFT" + Signature 1

↓

4 Complete → System Stamps Document Number + Date (Incremental Save #3)
→ Appends document number + date as Annotation (does not modify existing content)

↓

5 Organization Signature seals everything (Incremental Save #4)
→ Organization signature covers: Everything + Document Number + Date = Final Seal

Result: All Signatures Valid

Signature	Covers	Status	In Adobe Acrobat
Approver 1	Content + Draft	✅ Valid	"Signed, document modified after signing"
Approver 2	Content + Draft + Signature 1	✅ Valid	"Signed, document modified after signing"
Organization Stamp	Everything + Doc No + Date	✅ Valid	"Signed, no modifications" (Final)

Why do previous signatures remain Valid? Because Incremental Save = appending data, not modifying — Like adding an appendix to a book: it doesn't change Chapter 1, so the signature on Chapter 1 remains valid.

Conclusion: ERP is More Secure Than e-Saraban

Criteria	e-Saraban (Server Sign)	ERP (Digital Signature + Incremental Save)
Verify signer identity	❌ Server login only	✅ PKI Certificate
Detect modification	❌ Cannot	✅ Hash verifies every byte
Forge signature	❌ Possible (copy image)	✅ Impossible (needs Private Key)
Section 28 compliant	❌	✅
Assign number after signing	✅ Yes (not real sign)	✅ Yes (Incremental Save)
Court evidence	⚠️ Weak (forgeable)	✅ Strong (math proof)

"ERP systems with real Digital Signatures don't 'fail to do it' — they just do it 'differently from what you're used to' because they're more secure. The solution is Incremental Save, an international standard used worldwide. You get both the document number and valid signatures."

References

Electronic Transactions Act B.E. 2544 (as amended) — Sections 26, 28
ETDA — "Electronic Signature Guideline"
ETSI EN 319 142 — PAdES (PDF Advanced Electronic Signatures)
ISO 32000-2:2020 — PDF Specification (Incremental Save)
Adobe — "Digital Signatures in PDF" Technical Reference