General information, not legal advice. Any generated notice should be reviewed by a qualified lawyer before it is sent.

The sections

Most legal notices, across very different legal systems, contain the same building blocks:

1. Parties. Who is sending, on whose behalf, and to whom.
2. Date and reference. When the notice is issued, plus any contract, invoice or account reference.
3. Subject. A one-line neutral summary.
4. Facts. What happened, in chronological order.
5. Legal basis. The contract clause or statute relied on.
6. Demand. Exactly what the recipient is asked to do.
7. Deadline. By when.
8. Consequence. What the sender will do if the demand is not met.
9. Signature and service. Who signs, and how the notice will be delivered.

A schema

A JSON representation might look like this:

{
  "notice_type": "payment_demand",
  "jurisdiction": { "country": "IN", "region": "WB" },
  "language": "en",
  "issued_on": "2026-10-19",
  "sender": {
    "name": "A. Sender",
    "address": "…",
    "represented_by": null
  },
  "recipient": { "name": "B. Recipient", "address": "…" },
  "references": [{ "kind": "invoice", "id": "INV-0142", "date": "2026-07-01" }],
  "facts": [
    { "date": "2026-07-01", "text": "Invoice INV-0142 issued for goods supplied." },
    { "date": "2026-08-01", "text": "Payment fell due under clause 4.2." }
  ],
  "legal_basis": ["contract:clause-4.2"],
  "demand": { "kind": "payment", "amount": "185000.00", "currency": "INR" },
  "deadline": { "days": 15, "counted_from": "receipt" },
  "consequence": "civil_recovery_proceedings",
  "service": ["registered_post_ad", "email"]
}

A few design choices are worth explaining.

• Money as a string plus an ISO 4217 currency code. Floating-point numbers and legal amounts do not mix well. Store the exact decimal and format it only at render time.
• Facts as dated events, not a paragraph. Validation can then check that the facts are in order and fall before the issue date. The renderer can also turn them into numbered paragraphs.
• Deadline as a rule, not a date. "15 days from receipt" is what the notice says. The actual calendar date depends on when it is delivered, so store the rule and compute any concrete date separately.
• Jurisdiction as data. Wording, formalities and sometimes mandatory content depend on the country, and occasionally on the state or region.

Validation rules

Useful validation checks include:

• Date ordering. Every fact date is on or before issued_on, and references fall before the facts that rely on them.
• Required fields per notice type. A payment demand needs an amount and a currency. A tenancy notice needs the property address. A notice to quit needs the termination date.
• Statutory timing, where it applies. Some notice types carry fixed time limits. In India, for example, a cheque bounce notice under Section 138 of the Negotiable Instruments Act must be sent within 30 days of the payee receiving the bank's information that the cheque was returned unpaid. The drawer then has 15 days from receipt of the notice to pay. A model that knows the notice type can warn when the dates fall outside these limits.
• Party consistency. The recipient's name should match the name in the referenced contract or invoice.

Localisation is more than translation

Rendering the same model in another language raises problems that string translation alone does not solve:

• Date and number formats. 19/10/2026 and 10/19/2026 mean different things in different countries. Render dates with the locale, or spell the month out.
• Script direction. Arabic, Urdu and Hebrew need right-to-left layout. Set the dir attribute in HTML or the equivalent in PDF generation, and test mixed-direction lines containing numbers or references.
• Legal terms of art. Some concepts have no exact equivalent in another legal system. A glossary per jurisdiction is safer than relying on general-purpose machine translation for those terms.

Why a questionnaire fits

Once the notice is a schema, a questionnaire is the natural way to fill it in. Each answer populates a field, and conditional questions appear only when needed. The bank return date, for instance, is asked only for cheque bounce notices. The prose is then generated from complete, validated data instead of being edited from a template.

This is the shape of the workflow at LegalNoticeGenerator.com: you choose a notice type, answer a short set of questions, pick the country and language, and receive a structured draft to edit and download. Its list of 34 notice types shows how widely one underlying structure can be reused.