SAP CPQ Document Tags: A Practical Reference for Quote Templates

Every SAP CPQ administrator eventually meets the same failure. You upload a template, you generate a document, and instead of a value the output shows the tag itself, printed exactly as you typed it. No error, no warning, nothing in the interface pointing at which of the forty tags in the file is the broken one. Someone on SAP Community described it precisely, after his template upload hung until the session expired: “CPQ didn’t give any error message on front end side so I had to guess the error and finally I found it.”

I spend most of my week inside templates and scripts, and the cause is almost always one of three things: you are reading the reference for the wrong quote engine, you are using a tag the output format does not support, or Word has quietly rewritten your template. What follows is a reference to SAP CPQ document tags organised around what you are trying to put on the page, rather than around which family a tag belongs to. Everything here is checked against the 2609 documentation.

The reference you are reading may belong to the wrong quote engine

This is the part that costs people the most time, and nothing on screen warns you about it. SAP maintains two separate administration guides for document generation, one for Quote 1.0 and one for Quote 2.0, and the tag reference pages inside them carry identical identifiers while holding different content. Search for SAP CPQ document tags and Google hands back the Quote 1.0 version. If your tenant runs Quote 2.0, you are reading a document that is missing five entire tag families.

Those five are SECTIONS Loop, Involved Parties Tags, Tiered Pricing Tags, Usage Based Pricing Tags and SAP Subscription Billing Integration Tags. They exist only in the Quote 2.0 guide. Tiered pricing tags in particular are documented as usable only on the Quote 2.0 engine, and not at all in Excel templates.

The divergence runs the other way too. Special tags, the ST family, are described as supported in full on Quote 1.0. On Quote 2.0 the documentation names exactly eight that are supported: ST_LOGO, ST_USERFILE(), ST_USERFILE_IMG(), ST_PTYPE_PRICE(), ST_PTYPE_LISTPRICE(), ST_PTYPE_DISCOUNT(), ST_GROUP_LABEL() and ST_PTYPE_NETPRICE(). SAP does not say the rest are forbidden, only that these are the supported ones. In a migration, that is not a distinction I would bet a template on.

There is a second split underneath this one. From the 2311 release onwards every customer runs the new document generation engine, and a few things only became available there. AND logic in standalone conditions, written with &&, works only on the new engine. So do the B, b and U tag condition codes in DOCX. Templates written five years ago carry assumptions that no longer hold, which is one reason the template layer quietly ends up carrying business logic nobody documented. If you are rebuilding rather than patching, the order matters: decide first what the finished document has to do, which is how we get to quote documents that go out without anyone reformatting them, and only then work out which tags get you there.

Choosing SAP CPQ document tags by what you are printing

The official reference is split across eleven subpages, plus a separate troubleshooting deliverable, plus a tips page. Building one working template means opening six URLs across three guides. Here is the same material arranged by the job in front of you.

The header block and customer addresses

Quote level data comes from Q tags, and two details in that table save an afternoon each. The first is Q_QUOTE(VALID_UNTIL), which returns a date thirty days out by default. The offset goes inside the tag itself, so a 45 day validity is Q_QUOTE(VALID_UNTIL+45) and not a custom field.

The second is the address family. Q_BILLTO, Q_SHIPTO and Q_ENDUSER take the same arguments, with one exception that is easy to miss: CUSTOMERNUMBER is available for bill-to and end-user and is listed as not available for ship-to. The Q_OWNER table, similarly, has no FAX argument while the neighbouring tables do. Nothing in the interface tells you this. The tag simply comes back empty.

A related trap comes from quote tables rather than from the tag syntax. If a table or column name begins with an underscore, that underscore is part of the name and has to be reproduced in the tag. One practitioner spent a whole thread on exactly that: the structure worked fine in the quote, the tag returned nothing, and the answer was a missing leading underscore in the document.

Finally, a whole set of Q tags is marked obsolete and meant to be replaced by CTX equivalents, including Q_QUOTE(NUMBER), (TOTAL), (DATE_CREATED), (CURRENCY), (REVISION) and (STATUS). They still work. They are also the first thing I check when a template starts behaving differently after a migration.

The line item table

C tags are processed only when they sit inside a C2 loop. That single sentence explains most of the “my tag works in the header but not in the table” reports. The skeleton is <<C2>>, then an optional HEADER, then MAIN and LI blocks each closed with <<C_STOP>> before their end tag, then an optional FOOTER, then <<C_END>>. Miss the C_STOP and the loop does not stop, so every item in the quote gets rendered instead of the one row you meant to isolate.

Four rules around that skeleton are the ones I would memorise. Only Q tags are parsed inside the header, so anything item level placed there silently does nothing. A C2 loop cannot contain another C2 loop, although a condition inside one is fine. Splitting a loop across table cells, or across any other boundary, breaks the output entirely. And there has to be at least one blank space or a new line after <<C_END>> for the system to process it.

Volume matters here as well. SAP puts the performance warning at 500 tags and more, and separately notes that a Word template with an excessive number of C2 tags will not upload at all, with multi-section conversion as the recommended fix. That is a real ceiling on documents that try to be one giant template, and it is the point at which rebuilding the document rather than extending it becomes the cheaper option.

One numbering detail catches people out on nested products. C_ID returns an ordinal position, so child items displayed in the quote as 5.1 and 5.2 come out of that tag as 6 and 7. If the customer has to see the same numbering as the quote, the tag is C_VALUE(RolledUpCartItem).

Tables, containers and conditional blocks

Container tags have one placement rule that is absolute: they must sit in the main section of a C2 loop. Anywhere else and they are not processed.

Standalone conditions are the workhorse, and their syntax is narrower than it looks. Values on the right are separated by a pipe and evaluated as OR, = tests equality and ! tests difference, and the opening and closing condition tags have to sit on separate lines rather than inline. Conditions cannot be nested and cannot contain table tags. For AND you use &&, on the new engine only.

Two patterns cover most real requirements. To remove a line when a custom field is empty, the condition rides on the tag itself, in the form <<Q_TAG((<*CTX( Quote.CustomField(FieldName) )*>),=D>>, where D deletes the whole line. To print only the rows of a quote table that match a value, the condition goes inside the row block and tests the column tag against the value you want.

The full condition code list is short enough to keep on a sticky note. D deletes the line and d deletes the returned value. P and p insert a page break after and before. B and b apply bold to the line and to the value, and U uppercases. DC, DR, DCOL and DELETE_TABLE clear a cell, a row, a column and a table. In Excel templates only d and DR are supported, on either engine. This is the sort of thing I go through with administrators who keep these templates running in house, because an hour spent on it saves a week of rediscovery later.

Why a tag prints itself instead of a value

When SAP CPQ document tags fail, they fail quietly, and the cause is rarely where people look first. Three groups cover almost everything I see.

Word is usually the culprit

Most broken templates I open are not broken in their logic. They are broken in their formatting, and the documentation mentions this in passing rather than in bold. Do not switch fonts inside a single tag, and keep everything inside a C loop in one font. Use hard breaks only, because a soft break entered with Shift and Enter is a documented cause of uploads that crawl or never finish. Turn on paragraph marks and delete the stray characters that arrive with copied content.

Two file level rules belong in the same list. Template file names may contain only letters, digits, dashes, underscores and a single dot. Protected DOC and DOCX files cannot be uploaded at all. Both fail in a way that looks like a system problem rather than a naming problem, and that misreading is behind a good share of the issues that surface in the first weeks after go-live, where the fix turns out to be five characters long.

The same template behaves differently in Word, PDF and Excel

Output format decides which tags exist at all. Excel templates always generate as Excel files, so the only real choice is between DOCX and PDF. Inside Excel templates, Q_TAG_FILE is not supported, ST tags do not work, tiered pricing tags do not work, HTML tags that pull values from global scripts do not work, and tags inside Excel charts are not supported. Preview cannot be enabled for Excel documents either.

Word and PDF differ in a smaller but more irritating way. When generating Word output, line spacing is inserted automatically between paragraphs inside table cells, while PDF output keeps the paragraph options exactly as the template defined them. Same template, same quote, two tables that do not match. You find that out the day a customer puts both files side by side.

The cases where the tag genuinely is not parsed

Some literal tag output is a documented defect rather than a mistake. SAP knowledge base article 3335681 covers QUOTE_TABLE placed in the footer of a template, where the tag is printed instead of parsed. Article 3560828 covers a second container tag inside a C2 loop in an Excel template, where the processor drops it in the final iteration and prints the raw tags. Separately, and this one is by design, if C_PNAME or C_DESC contain formulas those formulas are not parsed and the document shows the tag content verbatim.

Two more symptoms look like tag problems and are not. A date arriving one day off is a time zone issue, fixed by setting the application parameter that disables time zone conversion for date fields. And on Quote 1.0, item names and descriptions are not translated at all if the dictionary chosen for document generation matches the dictionary the generating user already has selected, which means the feature looks broken precisely when you test it with your own account. Empty values, meanwhile, are usually upstream, and trace back to incomplete product attribute data rather than to anything in the template.

Three things to take away. Check which quote engine your tag reference belongs to before you trust a single line of it, because the two guides look identical and are not. Treat the output format as a capability list rather than a preference, especially with Excel. And when a tag prints itself, look at the formatting and the placement before you look at the syntax. One habit helps more than the rest: create a new template version whenever you add tags, so debugging stays limited to what you just changed. If a document set has grown past the point where anyone wants to touch it, a second opinion on a running system is usually faster than another afternoon of guessing.