Archive invoice attachments with Make

Outcome and scope

Save invoice PDF attachments into an agreed Google Drive folder, then keep a record that accounts staff can reconcile. A successful upload is different from an invoice being checked or approved. This workflow does not infer amounts, tax treatment or payment instructions from an email; it organizes the source document and leaves those decisions with the responsible person.

Use a pre-created folder mapping for the first release. A stable folder identifier is easier to reconcile than repeatedly creating folders from supplier names that may have spelling variations. Hold unknown supplier codes for review instead of dumping their documents into a shared general folder.

Prepare the fields and destination

Prepare these fields: Message ID, attachment ID, supplier code, received time, original filename, destination folder ID, uploaded file ID and review status. Keep source values separate from a reviewer’s confirmed values, and do not reuse an existing column for a different meaning. Create the first record with practice identifiers in a destination whose read and edit access matches the intended staff roles. Inspect the saved result from that role before using live information.

An archive filename can include a management reference, but keep the deduplication key independent of the display name. A corrected invoice arriving in another message is a new document requiring review, even if its filename matches an earlier attachment.

Build the workflow in order

Choose an intake label in Gmail and retrieve only messages in that scope. Start with one labelled sample and inspect the attachment name and binary data in the output. A filename ending in PDF is not evidence that the document is a valid invoice, so retain a separate human review state.

Process each attachment independently and look up a key made from the message ID and attachment ID. Skip an already recorded upload. For a new item, resolve the destination from a controlled supplier mapping rather than constructing a folder path from arbitrary email text.

Pass the attachment filename and data to Google Drive Upload a file, then record the returned file ID. Keep the original name and a reference to the source message. Open the stored file using the intended accounts role before allowing the scenario to handle a wider mailbox scope.

Work through a small example

For a practice case, place an invoice PDF and a purchase-order PDF in one email. They are two attachments, even though there is one message. Define whether both are archived or whether an uncertain document goes to review. Retrieve the message again and confirm that the same attachment keys do not create extra archive entries.

Handle changes during operation

For routine monitoring, compare message counts with attachment outcomes separately. Explain attachments that were absent, excluded, already archived or failed, and keep notification content limited to what the accounts team actually needs.

Estimate cost and usage

Estimate by attachments as well as messages. One email with five files may produce five storage operations plus ledger lookups and writes. Inspect the actual execution history of a small practice set. Include Make usage, Drive storage and the connected account’s contract; do not turn an unverified unit price into a guaranteed monthly total.

Investigate failures

If the upload succeeds but the ledger write fails, replaying the entire message can produce duplicates. Inspect the upload result and destination, then reconcile the existing file ID with the missing record. Do not bulk-delete matching filenames: two genuine invoices may share a generic filename, and a correction may intentionally be a separate document.

Review before release

Before release, test a normal record, one missing a required value, a repeated identifier and an edited record. Use message id to trace the saved result back to the source. The acceptance condition is: Each attachment key must point to one archived file; pending review is not the same as missing storage. Record the expected result before testing, compare it with the actual saved state, and resolve unexplained differences before increasing the scope.

• Getting started with Make
• Log Gmail messages in a spreadsheet
• Prevent duplicate processing in Make