Attachments

Some transactions need supporting documents — a vendor's invoice PDF that backs up the bill you entered, a receipt for an expense reimbursement, a contract that defines the terms of a recurring revenue stream, a delivery receipt for inventory. Attachments let you store these alongside the transaction so the next reviewer (or auditor) can click from the entry to the source document.

What can be attached

Most file types: PDF, JPG, PNG, HEIC, TIFF, DOC, DOCX, XLS, XLSX, TXT, CSV. Solid stores the file as-is (no transcoding) and the file's content type for display.

File typeUse
PDFVendor invoices, contracts, receipts, statements. The most common attachment.
JPG / PNG / HEICPhotos of receipts (gas-station receipts, paper meals, anything physical)
DOC / DOCXContract drafts, vendor agreements, signed terms
XLS / XLSXBackup workbooks, vendor-provided spreadsheets, calculation sheets
TXT / CSVLogs, machine-generated attachments

Maximum file size per attachment: 25 MB. Larger files (typically high-res photos or scanned documents) need to be compressed first; most photo apps and PDF tools have a "reduce file size" option.

What gets attached to what

Attachments link to a parent record. Supported parents:

Record typeUse case
Journal entriesReceipt for a check, vendor invoice for a bill, contract for a recurring entry
CustomersW-9, signed contract, sales tax exemption certificate
VendorsW-9, signed agreement, COI (certificate of insurance)
ItemsProduct spec sheets, photos
Fixed assetsTitle, manufacturer's manual, purchase receipt
LoansLoan agreement, amortization confirmation, lender's payment-history reports

A single transaction or contact can have multiple attachments — most users have one or two per record but heavily-documented items (a fixed asset with title, registration, insurance docs, and warranty) might have five or six.

Where attachments live

Attachments are stored inside the .solid file alongside everything else. They're encrypted at rest (same SQLCipher encryption as the rest of the file). Three implications:

  • Backing up the .solid file backs up every attachment automatically — no separate "do I have all my receipts" tracking
  • File size grows with attachments; a heavily-attached file can be a few hundred MB
  • Sharing the .solid file shares every attachment along with it

For files where attachment volume is large enough to slow file load times, an external attachment store option is in development — attachments would live in a separate folder/cloud-bucket and the .solid file would just hold pointers. Until then, the in-file model is what works.

Adding an attachment

Three paths:

  1. Drag and drop — drop a file onto an open transaction or contact form. Solid attaches it directly.
  2. The Attachments tab on any record — Attach File button opens a file picker.
  3. Camera capture (mobile bridge) — for photos of paper receipts, the Solid mobile companion app (in development) will support direct camera-to-attachment capture. For now, take the photo on your phone, AirDrop or email to your computer, drag onto the transaction.

After attachment, the file is stored, encrypted, and indexed. The transaction shows an attachment count badge; clicking opens a viewer.

The attachment viewer

The viewer renders:

  • PDFs inline (using the system PDF renderer)
  • Images inline at fit-to-window with zoom
  • Documents (DOC/XLS) open in their native app — Solid passes the file to the OS handler

Nothing about the viewer is networked — files don't leave the .solid file or your machine just to display.

Search and discovery

Attachment file names and (for PDFs) extracted text are indexed for the search palette (⌘K / Ctrl+K). Searching for "Linode invoice" finds:

  • Transactions with "Linode" in the payee or memo
  • Attachments with "Linode" in the filename
  • PDFs with "Linode invoice" in the extracted text (for OCR-able PDFs)

This makes the audit-trail story complete: someone asks "what did we pay Linode in March?" — search, find the entry, click through to the PDF receipt.

Retention

Attachments stay in the file forever — no auto-cleanup. Voided transactions retain their attachments; deleted contacts retain attachments via the audit trail. Disk-space management is your job (the in-file storage model means you're explicitly aware of the cost).

For tax compliance (which usually requires 7-year document retention in the US), the in-file storage model means you keep them as long as you keep the file. With Cloud Backup, an encrypted offsite copy of every attachment exists too, indefinitely (until plan lapse + 1-year restore window).

Bulk attach

For files with hundreds of receipts to process at month-end, the Bulk Attach dialog (Settings → Attachments → Bulk Process) lets you:

  1. Drop a folder of receipts/invoices onto Solid
  2. Solid OCRs each (PDFs and images) and tries to match by amount + date + payee
  3. Confirm matches; attach all in one batch

OCR is best-effort — clean PDFs match well; phone photos of crumpled receipts match poorly. Unmatched files stay in an "unattached" pool you can clear later.

Privacy and access control

Attachments inherit the file's password and encryption — anyone with the file's password can open attachments. In multi-user mode, role-based access applies:

  • Admin — full access to all attachments
  • Bookkeeper — full access (needed for daily work)
  • Read-only — can view attachments tied to records they can view, can't add new ones

There's no per-attachment access control — the model is "if you can see the transaction, you can see its attachments." For sensitive documents that warrant per-document access (legal contracts, HR documents), keep them outside Solid in a dedicated document-management system and attach a reference link or filename rather than the document itself.

API access

The REST API supports attachment management:

  • GET /attachments?parent_type=...&parent_id=... — list attachments for a record
  • POST /attachments — upload a new attachment (multipart form)
  • GET /attachments/{id} — download the file
  • DELETE /attachments/{id} — remove an attachment

API uploads go through the same encryption and storage path as UI uploads.

Common gotchas

File too large to attach. 25 MB hard limit. PDF compression (Adobe Acrobat, Smallpdf, online tools) usually drops a 30 MB scanned PDF to under 5 MB. Photos: shrink to 1024px wide.

Attached file but it doesn't appear on the transaction. Refresh the transaction view; attachments are loaded lazily. If still missing, check the audit log — sometimes an upload fails silently due to free-disk-space issues; the audit log records the failure.

Attachment search isn't finding text inside a PDF. OCR runs on attachment add. If the PDF was added before OCR was implemented (or the OCR quality is low), re-attach to trigger reprocessing. Pure-text PDFs are searched directly; image-only PDFs need OCR.

File grew dramatically after attaching a year of receipts. Expected — receipts add up. Compression helps; aggressive PDF optimization can shrink an attachment library by 50%+ without quality loss.

Cloud Backup with attachments takes forever. Initial backup of a heavily-attached file is slow because every attachment is uploaded once. Subsequent backups deduplicate (FastCDC catches that the same attachment hasn't changed) and are fast.

Need to remove an attachment but it's referenced by a posted entry. Soft-delete the attachment (mark inactive) rather than hard-delete; the audit trail expects every reference to resolve. Hard-delete is allowed only for unreferenced attachments.

Cross-references

Updated May 1, 2026
Edit this page on GitHub →
Was this helpful?

We use this to prioritize which docs to improve. No tracking, no email follow-up.