There's a law about letterheads. Section 12(3)(c) of India's Companies Act, 2013, in force since April 2014, requires every company to print its name, registered office address, CIN, phone, and email on all of its business letters, billheads, and official publications. The default penalty runs ₹1,000 for every day the omission continues, up to a lakh. This isn't theoretical: in the Ego Gear and Apparel case, business letters that went out without the CIN, email, and phone number for 475 days cost the company ₹1,00,000, and its managing director another ₹1,00,000 personally.
I like this law, and not only because we sell document software. It states plainly what most people sense but don't act on: a letterhead is a compliance surface, an identity claim, and, for a small company, often the only visual proof of competence a client ever sees. GST law piles on for invoices: get the GSTIN or a required field wrong and you've made a defective tax document, not an ugly one.
So why is this surface, of all surfaces, still maintained by hand?
Engineers already solved this problem — for pixels
Twenty years ago, every button in a web app carried its own hard-coded blue. Rebranding meant a find-and-replace across the codebase and a prayer. The industry's answer was the design system: colors, type, and spacing defined once as tokens, inherited everywhere, changed in one place. Nobody who has worked this way goes back.
Documents at small companies are still living in the find-and-replace era. The letterhead is a .docx template someone made in 2021. The address in the footer was typed, so when the office moved, it got updated in the template but not in the eleven proposals people had "saved as" from earlier documents. The bank details on invoices exist in nine files, in three versions, one of which is the old current account. Every fact your company states about itself is scattered as dead text across a folder tree, and the folder tree always wins.
The failure is in the architecture, not the care: hand-copied facts will drift, and the only question is which client notices first.
Three layers, strictly separated
The model we built Triplewave around, and the model I'd argue for even if you assemble it from other tools, separates a document into three layers with different owners and different rates of change.
Company facts are data, not design. Legal name, CIN, GSTIN, registered and branch addresses, phone, email, bank details. These belong in one place, maintained like a database record, because that's what they are. In Triplewave the letterhead and footer don't contain the address; they reference it: a footer holds {companyName} · CIN {cin}, and the value flows in at render time. When Droidsize's details change, they change once, and every document, including templates nobody has opened in months, is already correct. Section 12(3)(c) compliance becomes a property of the system instead of a proofreading task.
The brand kit is the system. Logo, palette, typography, and the composed letterhead and footer: designed once, by the one person in the company who cares about typography, and inherited by every document. You get beauty as a side effect; the point is that the other nine people in the company can't ship the wrong one by accident. A design system's real product is the absence of decisions.
Per-document overrides are the escape hatch, and the load-bearing part. Design systems die one of two deaths: they're abandoned, or they're obeyed until they're forked. The US client who needs Letter instead of A4. The premium proposal that deserves the more formal design. The day a rigid system meets these, someone copies the template, edits the copy, and now there are two templates, then nine. So overrides have to be first-class: this document uses Letter, this one uses the Atelier design, and everything not overridden keeps flowing from the kit. A template you have to copy is already a fork. The copy inherits nothing, drifts, and is the mechanism by which your old GSTIN survives into next year's invoices.
The test that keeps us honest
Anyone building (or buying) this kind of system needs an acceptance test, and ours is blunt: the system must reproduce our own real paperwork. Before Triplewave's design layer counted as done, we recreated Droidsize's actual letterhead in-product, pixel-close, and then did the same for a client's: a letter design and an offer letter, both compared against the originals. A document system that can only produce its own aesthetic hasn't separated design from content; it has imposed a different design.
If you're evaluating any tool in this category, run the same test with your own letterhead before you believe anything else it claims.
If you change nothing else
This is a product-adjacent essay from people with an obvious interest. The part below stands on its own, worth doing this week whatever software you use:
- Write the facts sheet. One page, one owner: legal name, CIN, GSTIN, addresses, phone, email, bank details. Date it. This is now the only authoritative source; every template cites it, no document invents it.
- Grep your own outbox. Search your sent PDFs and templates for your old address, your previous bank account, a stale phone number. The results are your drift rate, and the first time most companies do this, the results are humbling.
- Count your templates. If the number is greater than the number of document types you send, forks have happened, and at least one of them is wrong in a way you haven't found yet.
The claim underneath all this: brand consistency in documents is not a discipline problem, and treating it as one is why it never sticks. Memos about using the new template don't survive contact with a Tuesday deadline. Systems do. Your letterhead is going to be a design system either way: one you run on purpose, or one that evolves by copy-paste with a statutory meter running. The law, at least in India, has already picked which one it expects.