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 type | Use |
|---|---|
| Vendor invoices, contracts, receipts, statements. The most common attachment. | |
| JPG / PNG / HEIC | Photos of receipts (gas-station receipts, paper meals, anything physical) |
| DOC / DOCX | Contract drafts, vendor agreements, signed terms |
| XLS / XLSX | Backup workbooks, vendor-provided spreadsheets, calculation sheets |
| TXT / CSV | Logs, 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 type | Use case |
|---|---|
| Journal entries | Receipt for a check, vendor invoice for a bill, contract for a recurring entry |
| Customers | W-9, signed contract, sales tax exemption certificate |
| Vendors | W-9, signed agreement, COI (certificate of insurance) |
| Items | Product spec sheets, photos |
| Fixed assets | Title, manufacturer's manual, purchase receipt |
| Loans | Loan 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
.solidfile 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
.solidfile 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:
- Drag and drop — drop a file onto an open transaction or contact form. Solid attaches it directly.
- The Attachments tab on any record — Attach File button opens a file picker.
- 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:
- Drop a folder of receipts/invoices onto Solid
- Solid OCRs each (PDFs and images) and tries to match by amount + date + payee
- 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 recordPOST /attachments— upload a new attachment (multipart form)GET /attachments/{id}— download the fileDELETE /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
- Cloud Backup module — attachments back up automatically with the file
- Audit Log module — every attachment add/view/delete is logged
- REST API → Endpoints — programmatic attachment management