Disclosure. We sell a product in this space. Nothing below is a criticism of Aspose.Words, which is a good library — the argument is about where a template lives, not about who renders it.
The pattern
Vertical Dynamics 365 solutions very often generate their documents this way: a commercial templating library — Aspose.Words is the common one — driven by LINQ or C# against the Dataverse model, with the templates compiled into the application assembly.
It works. The output is good. Nobody rewrites this because the documents look wrong.
The cost is in the change, not the render
Follow one request through. A partner wants a line moved on a statement.
- The request goes to whoever owns the solution — usually the vendor, not the firm.
- A consultant edits templating code. It is code, so it is reviewed, built and tested.
- It ships in a release, on the release's schedule, not the request's.
- It is billed time and materials, because it was development work.
Typical range for that loop is 15–40 hours. The firm we based our case study on was averaging roughly $5,500 per change, six changes a year, which is about $33,000 a year to move things around on documents they already had. On top of that sat an Aspose.Words OEM licence and its annual support.
That figure is one firm's history, not an industry benchmark — but the shape is consistent, because it follows from the architecture rather than from anyone's inefficiency.
Why it follows from the architecture
A template compiled into the application is, correctly, treated like application code. It gets code review, a build, a test cycle and a release slot, because a bad deploy of it can take down something else in the same assembly.
None of that is waste. It is the appropriate process — for code. The problem is that the artefact being changed is a page layout, and a page layout does not need any of it.
What changes when a template is configuration
Move the template out of the assembly and into data, and the release process stops applying to it. In SSS DocGen a template is three things held as rows in your own Dataverse:
- a manifest.json describing it,
- FetchXML datasets that fetch what it needs,
- and a Handlebars template.html that lays it out.
Editing the layout is editing markup. It previews locally, ships by an idempotent alternate-key upsert, and is live in every channel that calls the API — the model-driven app, Power Automate, code apps, Power Pages — without a compiled-code release.
The part that is not free, and is the point
Business logic must not move into the template. Totals, amount due, aging buckets, credit-balance detection and address resolution stay server-side, in what we call the Enricher.
That is a deliberate constraint and it costs you something: genuinely new logic is still a development change, priced accordingly ($1,500 rather than $850, in our case). What you buy for it is that the template stays safe to hand to someone who is not a developer. A template with business rules in it is code again, wearing different syntax, and it will re-acquire the release process it just escaped.
The failure mode worth designing for
The dangerous failure in document generation is not an exception. It is a document that renders successfully and is wrong — a truncated dataset, or a child row that did not attach to the parent it belonged to, producing a plausible statement with the wrong money on it.
Any system you evaluate should be asked how it surfaces that. DocGen returns non-fatal problems in a warnings field so a caller can branch on it rather than trusting HTTP 200. Whatever you use, do not let the answer be "it throws if something goes wrong", because this class of failure does not throw.
When compiled templating is still right
- Your documents do not change. If templates have not moved in three years, the entire saving above is zero and you should not spend a euro on this.
- You need Word output, not PDF. Aspose's document-model work is real; an HTML-and-Chromium pipeline produces excellent PDFs and is not a .docx editor.
- Layout requirements exceed what HTML and CSS paged media do well. Most statements and invoices do not, but some regulated forms genuinely do.
- It is somebody else's product and you are happy. If the vendor absorbs change costs in a fixed fee, the incentive problem this article describes does not exist for you.
The question to ask
Not "which renderer is better". Ask: how many times a year do our documents change, and what does each change cost us in money and in elapsed weeks?
Multiply. If the answer is small, keep what you have. If the answer is a five-figure line item for moving text around, the renderer was never the thing to change — the release process attached to it was.