How EspoCRM PDF templates turn records into quotes, invoices and documents
A sales or finance team that needs printable, consistent quotes, invoices and records should design its PDF templates before it builds any workflow that generates or stores them. In EspoCRM, a PDF is produced from a record, so the template decides what the document says, which fields it shows and how it is laid out. Each template belongs to an entity type, which means a quote template, an invoice template and a summary of an account or opportunity are separate designs with separate field lists. The pillar facts confirm the scripting and access features that surround printing, but they do not describe the PDF settings themselves. Confirm the template options, the supported entity types and the output behavior in the EspoCRM documentation for your version before you commit to a layout.
Start with the data behind each document. A quote total is only as correct as the values saved on the record, so calculated line totals, taxes and discounts are best produced by Formula Script before-save scripts. The Formula documentation describes Formula as the built-in scripting language used in before-save scripts, which is where those values can be set before a record is stored. If quotes and invoices come from an official sales documents extension, check which entities and fields that extension adds before you design templates against them, and keep any custom field a template depends on under change control. Then decide which roles can print or generate PDFs. A printed document carries customer and pricing data out of the system, so print access should follow the same role model as reading the record, and you should test that a restricted user cannot print a record they cannot see.
Test the output before users depend on it. Build each template against sample records that cover the difficult cases: long line-item lists, multiple currencies if you use them, customer names with non-Latin characters and empty optional fields. Non-Latin text is where font and rendering choices matter most, so confirm which fonts and PDF engine your version supports and whether the character sets your customers use will display correctly. Mass printing is the other limit to verify. The platform may cap how many records can be printed at once, so confirm that cap for your version and test a realistic batch before the team relies on bulk output. In a quote, ask for each template, entity type, font requirement and test batch to be listed as a separate deliverable, with written sign-off on sample output, so the scope of template work is settled before the build starts.
Which PDF template settings fit each document type
This table compares the main PDF template choices for quotes, invoices and plain record printouts in EspoCRM. Read each row as a decision: what it fits, what it constrains, and what to confirm in the EspoCRM docs for your version before you build.
| Setting | When it fits | What it constrains |
|---|---|---|
| Template per entity type | Quotes, invoices and records each need different fields, legal wording or branding | Each template must be maintained separately, so changes to one document type do not carry over to others |
| Shared template for several entity types | Simple record printouts where the same layout serves most entities | Entity-specific fields may not appear cleanly, so check the placeholders each entity exposes |
| Line item content | Quotes and invoices that list products, quantities, prices and totals | Line items depend on how the sales documents are modeled; confirm the module and field names in your version |
| Fonts for international text | Documents in languages with non-Latin scripts or accented characters | Fonts must be available to the PDF engine on the server; test glyph coverage before rollout |
| Language and locale | Customers receiving documents in more than one language or currency format | Labels, dates and number formats may need separate handling per locale; confirm what the defaults cover |
| Role access to printing | Sales users print quotes, while finance or service users need only specific documents | Print permission sits alongside record access, so a user who cannot view a record cannot print it |
| Mass printing | Batch output for renewals, statements or bulk invoice runs | Large batches are bounded by documented limits and server resources; confirm limits and test with realistic volumes |
How templates differ for quotes, invoices and records
A quote is a proposal that the customer may accept, negotiate or reject, so its template must show current pricing, validity terms and the line items that the sales team expects to change. The template usually pulls from the Quote record, its line items, the linked Account and the contact who receives it, and the owner's details for the signature block. Because the document is expected to change, the team should decide early whether a quote is regenerated on each print or frozen once it is sent.
- Fields and related entities: Quote number, issue and expiry dates, billing and shipping addresses from the Account, line items with quantity, unit price, discount and tax, and the terms text.
- Data to check before printing: Totals recalculated after the last line change, discount and tax values that match the agreed price book, and an expiry date that is after the issue date.
- Version control: Confirm whether a printed quote is a snapshot or a live view, and tell sales staff which one applies so an old PDF is not treated as current.
- Customer-specific content: Check that terms and currency match the customer's contract, since a template reused across regions often carries the wrong defaults.
- Review step: Have the sales owner compare the generated PDF with the record for one sample quote per template before the template is released to the team.
Before release, ask the implementation partner to show how a quote changes after a line item edit, and confirm with your finance team which totals rules the template must follow.
An invoice is a financial record that must stay fixed once issued, so its template must print only data that cannot change without a documented correction. The template usually pulls from the Invoice record, its line items, the seller and buyer details, payment terms and the tax registration numbers that your jurisdiction requires. The main design question is how the team prevents an issued invoice from being altered, and how it issues a credit note or a corrected invoice instead.
- Fields and related entities: Invoice number from a controlled sequence, issue and due dates, legal entity name and address, buyer tax identifier, line items, tax breakdown and payment instructions.
- Data to check before printing: Numbering that has no gaps or duplicates, tax calculated by the rule set your finance team approves, and currency and rounding that match the ledger.
- Locking: Confirm with the vendor and your own environment which record states and field permissions can be used to block edits after issue, and test that a user without the right role cannot change them.
- Corrections: Agree how a wrong invoice is cancelled or replaced, so the printed history stays complete and traceable.
- Review step: Have finance reconcile the printed totals against the ledger for a sample of issued invoices, and have someone outside the template build confirm the legal wording with your tax or legal advisor.
Ask for a written description of the locking mechanism and a test log before accepting the invoice template for production use.
Record printouts serve two audiences: internal reviewers who need a complete view of a case, account or contract, and customers who receive a handover document. The template usually includes the main record, selected related records such as activities, notes or attachments, and a clear statement of what was excluded. Because a record printout can expose more personal data than a quote or invoice, the team must decide what each audience may see before the template is built.
- Fields and related entities: The core record fields, selected panels such as contacts, opportunities or cases, and a print date and user name that identify who generated the file.
- Scope of content: Decide which related records are included for internal review and which are removed for customer handover, and document that rule in the template name or header.
- Personal data: Check that internal notes, private comments and fields from other customers are excluded from anything sent outside the company.
- Access to printing: Confirm which roles can print each template, since a user who can view a record may not be meant to export it as a file.
- Review step: Have a second person compare the printed file against the role permissions of the intended recipient for one sample record of each type.
Ask the team to show, with a test record, that the handover version omits internal content and that the printed user and date fields are correct.
How to set up PDF templates in a working instance
This sequence takes a test instance from confirmed version and stack to tested quote, invoice and record templates, with fonts, languages and print access checked before anything reaches production. Each step ends with a comparison or test the team can repeat after changes.
Confirm version and PDF capabilities
The platform owner records the EspoCRM version the instance will run, using the releases page to confirm the current 10.x release and the upgrade notes that apply to it. Then they read the PDF and template sections of the official documentation for that version and list what it supports: template scope per entity type, available functions, font handling and any limits on mass printing. Anything the docs do not state is added to a question list for the vendor or a test. Done when the version, the documented capabilities and the open questions are written down and approved by the project lead.
Build a test instance on a supported stack
The infrastructure team deploys a non-production instance on the PHP, database and web server combination listed in the server configuration documentation for the chosen version. They use the installation script for a quick start or a manual install if the hosting standard requires it, and they configure the scheduled job runner, since background jobs depend on it. Done when the instance loads over HTTPS, a test administrator can sign in, and a scheduled job runs and logs a successful execution.
Map entities and fields for each document
The business analyst and a finance representative list each document type (quote, invoice and any record printout) and the entity that feeds it, such as opportunities, accounts, contacts or products. For every template they list the fields and related records it needs, including line items, tax, currency, payment terms and addresses, and they mark which fields are required for a valid document. Any custom field is created in the Entity Manager at this point. Done when the field inventory matches the entity layouts in the test instance and a reviewer has signed off that no field needed on a printed document is missing.
Build one template per entity type
The administrator creates a separate PDF template for each entity type identified in the previous step, using the template editor and the field names from the inventory. Each template is kept simple at first: header, parties, line items and totals, with conditional content added only after the basic layout renders correctly. The team saves the template settings and notes the version in the change log. Done when each template produces a PDF from a sample record, and a side-by-side comparison with the approved reference document shows matching fields, totals and layout.
Set font and language handling
The localization lead identifies every language, alphabet and currency symbol used on printed documents, then checks the font and encoding options described in the PDF documentation for the version in use. They render a test record containing accented characters, non-Latin text, long names and the currency symbols that apply. If the default font cannot display a character, the team tests the alternative the docs describe and records the result. Done when rendered PDFs show every test character correctly and match the sample text character by character.
Grant print access by role
The security administrator creates a test role for each group that needs to print, such as sales, finance and service, and a separate test user for each role. Access follows the role permissions for the entity and the print action, and the team avoids using admin accounts for this check, in line with the guidance in the security documentation. Each test user prints an allowed document and attempts a restricted one. Done when allowed users receive the correct PDF, restricted users are blocked, and the access matrix is saved with the test results.
Test output with sample and edge-case records
The QA lead prepares sample records, including typical deals, a record with many line items, a record with missing optional fields, and one with the largest discount or tax combination the business uses. Each record is printed individually and compared with its reference document, and then a small batch is printed to observe how the instance behaves. Mass printing limits are confirmed in the documentation before any larger batch is tested. Done when every edge case matches its reference, the batch completes without errors, and the test log is archived with the template configuration for the next review.
Who can print, and what the output exposes
A PDF is a copy of record data that leaves EspoCRM the moment someone downloads it. The cards below cover who can trigger printing, where the output goes, how template edits change issued documents, what related data a template pulls in, and what evidence you can keep afterward.
Role access to print actions
Printing is governed by the same role permissions that control reading the underlying records, so a user who can open a quote can usually generate its PDF. Check the role for each entity type that has templates, and confirm that print access is granted separately from edit and export rights where your version allows it. Test with a non-admin account, because administrator roles bypass most restrictions and hide gaps. Keep a short matrix of which roles can print which templates, and review it whenever a team is added or a portal role is created.
Printed documents leaving the system
Once a PDF is downloaded, EspoCRM no longer controls who sees it, where it is stored or whether it is forwarded. Quotes and invoices often carry pricing, discounts and customer banking details, so a single exported file can expose more than a screen view. Decide which templates are allowed to be emailed from the system, which are download only, and whether portal users can retrieve them. Ask your team to confirm how downloaded files are stored on endpoints and shared drives.
Template changes that alter issued documents
Because a PDF is rendered from the current template and current record data, editing a template or a formula can change how an old record prints today. An invoice reprinted after a template update may not match the copy the customer already received. Set a change process for templates: named owners, a test record for each template, and a dated changelog. Where legal or accounting rules require the original document, store the generated PDF as a file attachment at issue time rather than relying on regeneration.
Related records pulled into templates
A template can reference linked records such as the account, contact, assigned user or line items, so a user who prints a quote may expose fields they could not open directly. Map every placeholder to its source entity and confirm that the printing user can read those related records under their role. Pay particular attention to contact or account fields that hold personal data, internal notes, cost prices or margin figures that should never appear on a customer-facing document.
Field visibility inside templates
Templates do not automatically respect field-level restrictions in the way list and detail views do, so a field hidden from a team in the layout may still print. Build a field inventory for each template, list every attribute it prints, and compare that list against the field access settings for each role that can print it. Use separate templates for internal and customer-facing output rather than relying on conditional text to hide content.
Logging of print activity
Whether EspoCRM records each print or download event, and for how long, depends on the version and on the logging you configure, so confirm this before you rely on it for an audit trail. If the platform does not log prints, rely on your own controls, such as server access logs, file attachment history and documented procedures. Ask your implementation partner to show, on a test instance, exactly which actions produce a traceable entry.
Designing PDF output for international fonts and languages
Font support and character encoding decide whether names, addresses and currency symbols print correctly on a quote or invoice. A PDF that looks fine with Latin names can silently drop characters, substitute a fallback glyph or misplace an amount once a customer's name contains accented letters, Cyrillic, Arabic, Hebrew, Devanagari or CJK characters. The template you design in EspoCRM is only half the job. The other half is the server side: which fonts are installed or embedded, how the PDF engine handles Unicode text, and whether the template data is stored and passed as UTF-8 from the database through PHP to the renderer. Treat a missing glyph as a defect, not a cosmetic issue, because a misspelled counterparty name on a contract-related document can cause real business friction.
Build a test set before you approve any template. Use a fixed group of records that covers every script your teams actually sell into, including names and street addresses that mix scripts, a right-to-left address and a line of text with both right-to-left and left-to-right runs. For multi-currency, include amounts in currencies with different decimal conventions and symbols that sit before or after the number, and check that totals, taxes and line items still align. Render each test record to PDF for every entity type and role that will print it, then compare the output against the source data by copying text out of the PDF. Confirm that font files for each script are installed on the server or embedded in the output, and record which font file covers which script so the setup can be reproduced after an upgrade or server move.
Before you commit to a design, confirm with the EspoCRM documentation which fonts, font handling and PDF engine options your EspoCRM version supports, and whether right-to-left layout and CJK line breaking are handled by the engine or must be designed around. Ask the same questions of your hosting setup, since fonts installed on a development server are often missing on production. Plan a retest after every EspoCRM upgrade and after any change to PHP or the rendering library, and ask your implementation partner to write the font inventory and test set into the handover documentation.
Limits to confirm before designing PDF output
PDF output depends on limits and components that differ between deployments, so none of the design should be fixed until these points are checked in your own environment. The cards below cover batch behavior, the rendering engine, fonts, large related lists and whether a capability belongs to core or to an extension.
Mass printing limits and batch behavior
Ask how many records EspoCRM will print in one action, whether the batch runs in the browser request or in a background job, and what the user sees when a batch is large or partly fails. Confirm this with the vendor documentation for your release, then test a realistic batch of invoices on a staging instance. Record the time taken, memory use and any timeout. A quote template that works for one record can still fail when a sales manager prints a whole list, so the test should use the largest batch your teams plan to run.
PDF engine in your deployment
Determine which PDF rendering component your installation uses, where it runs and which version it is. The engine controls how HTML or template markup becomes a PDF, including page breaks, table handling and image embedding. Check whether the engine is bundled with your chosen installation method or must be installed on the host, and whether your hosting model allows that. Render a sample quote with tables, images and multi-page line items before you commit to a layout design.
Font availability on your server
Templates only render characters for which the server holds a font file. Confirm which font families ship with your installation and which you must add yourself, especially for non-Latin scripts, currency symbols and accented names used in invoices. Check that licensing permits embedding the font in generated documents. Print a test record containing names and addresses in every language your customers use, and inspect the output for missing glyphs or substituted characters.
Performance with large related lists
A template that lists line items, payments or activities pulls related records at print time, so a quote with hundreds of rows can slow generation considerably. Confirm how the template loads relations and whether the data it needs is available without extra loading. Test an opportunity with the largest number of line items your sales team realistically creates, and measure the response time. If the output is too slow, the design may need fewer related fields or a summary section rather than a full list.
Core feature or official extension
Some document capabilities, such as those tied to sales documents, inventory or reporting, may come from an official extension rather than the core product. Check the feature list for your release and the extension documentation before promising a feature to stakeholders. If a required capability sits in an extension, add its license, installation and upgrade effort to the scope, and confirm it works with your EspoCRM version. Ask the vendor or DeployOpen to show the exact module that provides each required output.
What do PDF template projects cost and require from our team?
What drives the cost of an EspoCRM PDF template project?
The main driver is how many documents you need and how much logic sits behind them. Cost grows with the number of entity types that print (quotes, invoices, orders, records), the number of layouts per document, conditional sections, calculated totals that depend on formula logic, multi-language output, and branding requirements such as fonts and logos. A set of two or three simple templates costs far less to define and validate than a set covering several entities with tax rules and approval states. Ask any partner to price the work from a written list of templates, fields and sample records rather than a general request for "PDF documents."
How long does it take to validate a set of PDF templates?
Validation time depends on how many templates exist, how many sample records each one needs to be tested against, and how many rounds of review finance and sales require. Plan for review cycles rather than a single pass, because most corrections come from edge cases such as long line-item lists, missing optional fields and currency formatting. DeployOpen will state the duration in the written scope once the template list and review process are agreed. Ask for the schedule to show each review round as its own milestone.
What do finance and sales staff need to provide for sign-off?
Finance and sales staff need to supply the authoritative wording, numbering rules, tax and rounding rules, legal footer text and examples of documents they already accept. They also need to confirm which fields appear on each document and who is allowed to print them. Sign-off works best when a named approver reviews printed samples from real test records against the approved examples, and when changes after sign-off go through a written change request. Without a named approver, template changes tend to stall or repeat.
Can an internal EspoCRM administrator maintain the templates after handover?
Yes, a trained administrator can usually edit templates, but only if the handover includes documentation of each template's fields, the logic it depends on, and the test records used for validation. Maintenance is mostly routine edits to wording, layout and fields. Changes to calculated values, conditional logic or multi-language output need more careful testing. Ask whether the handover covers a regression set of sample records that the administrator can rerun after each change.
What changes when PDF templates must be redone after an EspoCRM upgrade?
Upgrades affect templates when the underlying entity fields, formula functions, extensions or PHP runtime change. Before a major upgrade, the team should export current templates, list every field and formula they use, and check each one against the new release notes. Testing then repeats the same validation rounds used at launch. EspoCRM 10.0.0 was released on July 2, 2026, and the EspoCRM upgrade docs should be read before scheduling work. Ask any partner to include upgrade regression testing for templates in the maintenance scope.
What does a template project cost recurrently after launch?
Recurring costs come from keeping the templates correct over time, not from the software license. EspoCRM's open-source edition can be downloaded and self-hosted for free, according to the EspoCRM pricing page, so the recurring spend is internal staff time, hosting and any support retainer. Plan for periodic reviews when tax rules, branding or legal wording change, and for regression checks after each EspoCRM or PHP update. A support retainer covers these checks if you want them outsourced.
Which sample data should we prepare before requesting a quote?
Prepare a small set of anonymized or test records that cover your hardest cases: many line items, discounts, multiple currencies, missing optional values, and long customer names. Include one approved example of each document type. Clear samples let a partner estimate effort accurately and let your finance team check output without touching live customer data. Confirm with your data protection lead that test data is handled under your internal rules.
How DeployOpen scopes and delivers EspoCRM PDF templates
DeployOpen plans, builds, tests and documents EspoCRM PDF templates for quotes, invoices and records inside your own infrastructure. Each engagement starts from a written scope that names the entities, roles, languages and output rules involved before any template work begins.
How we scope
- We list each entity that needs a template, such as quotes, invoices and account or contact records.
- We confirm which roles may print, how many records a mass print should handle, and who approves layouts.
- We agree on fonts, languages and PDF engine choices in writing before the build starts.
How we build
- We design template layouts per entity type and test them against realistic sample records with your data fields.
- We check character rendering for the languages and currencies your documents use, including non-Latin scripts.
- We keep custom code and template files organized so they can move through upgrades without rework.
How we hand over
- We deliver templates, configuration notes and role settings documented for your administrators to maintain.
- We walk your team through test prints, known limits on mass printing and steps to add a new template.
- We document how to back up template files and restore them on a new server after a migration.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can retest templates when you change EspoCRM versions, PDF engine settings or fonts.
- Confirm with us in the quote which support hours, response expectations and upgrade work are included.
