Assemble the transmittal
A transmittal template stitches the ITB, the confirmation, and the invoices into one packet with source tabs, then carries a computed bid total derived from data already on the case.
By now the bid case holds everything: the invitation to bid and its scope, the confirmation you sent back, and the invoices that have been landing in the case as they arrive. Four documents, one case, one running record. The last job is to hand all of that to the GC as a single packet with a cover number that reflects the real total, not a figure someone re-typed from a calculator. That is two pieces of machinery meeting in one template: the source tabs that order the pages, and a transform that reads the numbers already sitting in case data and does the arithmetic for you.
This template, and the case pipeline it draws from, live in The Operation (Pro). Source tabs themselves work on any tier, but a packet that aggregates several documents off one case needs cases, which is Pro.
Stitch the packet
The transmittal has no PDF of its own at first: it is an empty shell whose pages come entirely from other documents. You build the page order in the document bar, the row directly above the preview canvas, by adding one source tab per piece.
The +Add popover lists Sources from this workspace at the top (each with its category chip and any automation chips) and an Other section below with Upload new file, Blank page, and Add form. A tab can point at a workspace document source asset (the preferred path, a reusable PDF managed under the Documents tab) or at another template's output, which is exactly how a packet pulls in the ITB and confirmation you already built: the tab references the upstream template by ID and emits its generated pages into the combined output. Drop a Blank page between sections if you want a separator or stapling space. The full mechanics, the three bar layouts, per-tab settings, and how orphaned tabs render, are in Combining & reflowing documents; this tutorial only walks the path.
Carry a total it computes itself
A transmittal cover usually states the bid total. Typing it in by hand is the exact mistake this product exists to prevent: the moment an invoice changes, the cover is wrong and nobody notices. Instead, add a computed output that sums the line amounts already extracted onto this case, so the figure on the cover is derived, not re-keyed.
The expression is JSON with an op and args. To total every line amount on the case, including ones extracted later, point a sum at a key pattern:
{"op":"formatCurrency","args":[
{"op":"sum","args":[{"ref":"keys:^line_item_\\d+_amount$"}]},
{"literal":"USD"}
]}
The keys: reference gathers every value whose key matches the regex, so adding a fifth invoice to the case folds its amount into the total with no edit to the template. The whole catalog of operations, math, aggregates, date math, conditionals, plus how references resolve, is in Computed expressions. A days-remaining figure works the same way: {"op":"daysBetween","args":[{"ref":"$today"},{"ref":"bid_due_date"}]} counts down on its own because $today re-evaluates on every view.
For values that come from around the case rather than from inside it, the prepared-on date, the company name and address on the cover, use a binding instead of a formula. A binding output set to System stamps the day the packet is actually generated; Company profile pulls your address from one central place. Both resolve fresh at generation and are never saved to the case.
Run it once, then hand it off
Generate the packet from the case, exactly as you ran every earlier template, and the pages assemble in tab order while the computed total recomputes against the case's current numbers. If one invoice in this packet is an outlier the run misreads, the Special AI Instructions box in the autofill review modal is the right tool: it applies to that single run only and is never saved to the template, so a one-off correction never contaminates the next packet you build.
That closes the bid lifecycle. One case absorbed an invitation, a confirmation, and a stream of invoices, kept its own running history, and produced a single packet whose cover number it calculated itself. To go deeper on the mechanics this series leaned on, the source tabs and the transform reference articles above are the next stop, and Cases and data explains the data model every one of these steps wrote into.