Singapore Retail Invoices, Receipts & Delivery Notes to Excel

A Singapore retail finance team can convert supplier tax invoices, simplified receipts, and delivery notes into one Excel intake by extracting one consistent column set, with conditional rules for UEN, 9% GST, document number, delivery match, and a review flag. Required fields (source file, document type, supplier name, document date, gross total or quantity, review flag) are captured from every document. Conditional fields (UEN, GST registration number, GST amount, line-item detail, delivery quantity) are captured only when the document carries them. Missing values that should be present trigger review flags so the bookkeeper can sort and clear gaps before posting to the ledger or claiming GST input tax.

The reason the schema is built this way, and not as three separate worksheets, is the audit window. According to the IRAS Record Keeping Guide for GST-Registered Businesses, IRAS requires GST-registered businesses in Singapore to keep their business and accounting records, including tax invoices and receipts, for at least five years. Five years of mixed retail purchasing means thousands of rows that must trace back to the original document on demand. A unified intake that preserves a source-file reference and a document number on every row, regardless of document type, is the design that survives an audit; three parallel workbooks built from three separate workflows do not.

The pile is mixed because retail purchasing is mixed. A typical week brings GST-registered supplier tax invoices for stock and back-of-house spend, simplified receipts under S$1,000 from smaller vendors and POS purchases that arrive as printed slips or phone photos, and delivery notes that travel with the goods rather than the invoice and need to be matched later. Building one Excel layout that accepts all three side by side, rather than maintaining three pipelines for the same close, is the practical move for any Singapore retail bookkeeper, outsourced practice, or finance manager looking up Singapore retail invoices receipts delivery notes to Excel as a working problem to solve this month.

This is an intake-side workflow, not an issuing-side template, and not the InvoiceNow case. Suppliers who already send machine-readable Peppol XML belong in a different pipeline; if that's the workflow, convert Singapore InvoiceNow PINT-SG XML invoices to Excel covers the structured-XML side. The retail bookkeeping reality on the ground is still mostly PDFs, scans, and photos, and that is the pile this article addresses.

The rest of the article walks through the unified column set, the IRAS-grounded conditional logic, the retail-specific operational rules around outlets, payment mix, and delivery matching, the review-flag triggers, and the prompt-based extraction that turns the design into one repeatable batch job.

The Unified Column Set: One Spreadsheet for Three Document Types

The intake spreadsheet has 21 columns. Each one is either required across all three document types, conditional on the document carrying that field, or flag-on-missing when the document type implies the field should be there. Building the layout this way is what keeps a Tax Invoice row, a Simplified Receipt row, and a Delivery Note row legible side by side.

The columns, in order:

source file, document type, supplier name, supplier UEN, supplier GST registration number, document date, invoice or receipt number, delivery-note number, item description, SKU/product code, quantity, unit price, net amount, GST amount, GST rate, gross total, payment status, outlet/location, delivery date, matched invoice/reference number, review flag.

The behaviour of each column across document types:

Column	Tax Invoice	Simplified Receipt	Delivery Note
source file	required	required	required
document type	required	required	required
supplier name	required	required	required
supplier UEN	flag-on-missing	conditional	conditional
supplier GST registration number	flag-on-missing	conditional	not applicable
document date	required	required	required
invoice or receipt number	flag-on-missing	flag-on-missing	not applicable
delivery-note number	not applicable	not applicable	flag-on-missing
item description	conditional	conditional	conditional
SKU/product code	conditional	conditional	conditional
quantity	conditional	conditional	required
unit price	conditional	conditional	not applicable
net amount	conditional	conditional	not applicable
GST amount	conditional	conditional	not applicable
GST rate	conditional	conditional	not applicable
gross total	required	required	not applicable
payment status	conditional	conditional	not applicable
outlet/location	conditional	conditional	conditional
delivery date	conditional	not applicable	required
matched invoice/reference number	conditional	not applicable	flag-on-missing
review flag	required	required	required

A few of these rules deserve direct comment, because they shape how the rest of the article reads.

Document type is the gating column. It is the first decision the spreadsheet makes about each row, and the rules for every other column flow from it. A row tagged Tax Invoice triggers UEN and GST-registration validation, expects a non-empty invoice number, and reconciles GST against the 9% rate. A row tagged Simplified Receipt relaxes the UEN and GST-registration requirement (IRAS does not mandate them on a simplified tax invoice for supplies under S$1,000) but checks that the gross total stays below the threshold. A row tagged Delivery Note skips price and GST columns entirely, captures quantity as a required field, and enforces a matched invoice reference instead of an invoice number.

UEN and GST registration number are conditional, not optional. They sit on the conditional line because not every document is required to display them, but where the document type implies they should be present (a full tax invoice from a GST-registered supplier), the cell is blank only as a flag, not as a clean state. The next-but-one section covers the trigger logic.

Line-item depth is captured at intake but not exhaustively. Item description, SKU, quantity, unit price, and net amount are conditional fields because retail purchase documents vary. A full tax invoice for stock typically itemises every line; a simplified receipt for a S$23.40 purchase from a small supplier typically does not, and the gross total is the only number on the document. A delivery note carries item, SKU, and quantity but rarely price. The unified intake captures what each document carries; teams that need exhaustive line-by-line extraction from delivery notes, including reconciliation of unit-level quantities against the matching invoice, can use the deeper guide on how to extract delivery note PDF line items into a spreadsheet for the document-type-only workflow. Similarly, when the batch is receipt-heavy and the priority is reading receipts at scale, the dedicated workflow on how to scan paper and digital receipts into Excel for bookkeeping goes deeper than the intake-level capture this article describes.

The matched invoice/reference number column is the join key for delivery matching. When a delivery note and the matching invoice both land in the batch, the matched reference is what allows the spreadsheet to surface delivery-quantity vs invoice-quantity mismatches. On a delivery note row, this column is flag-on-missing because a delivery without any invoice reference cannot be reconciled later. On an invoice row, the same column is conditional because the supplier may or may not have printed the delivery-note reference back on the invoice.

Gross total is required on the priced documents, not on delivery notes. A delivery note that carries no price is still a valid intake row, with quantity received against the matched invoice reference being what the row contributes. Forcing a gross total on those rows would make the column meaningless across the dataset.

The 21-column layout is wider than what most retail bookkeepers start with, but it is what the mixed batch actually demands. Anything narrower forces a downstream workaround.

IRAS-Grounded Conditional Rules: When UEN, GST, and the Simplified Threshold Apply

Each conditional rule in the schema maps to a specific IRAS position. The point of this section is not to replicate the regulatory walkthrough; for the canonical rundown of what a Singapore tax invoice must show under IRAS rules, readers should use the dedicated guide. The point here is the operational layer: which IRAS rule is encoded into which column behaviour, so the spreadsheet's conditional logic isn't arbitrary.

The simplified-vs-full tax invoice line sits at S$1,000. A tax invoice for a supply not exceeding S$1,000 (including GST) may be issued by the supplier as a simplified tax invoice with fewer required fields. Above that figure, a full tax invoice is needed. This is the rule that makes the supplier UEN and GST registration number columns conditional on Simplified Receipt rows but flag-on-missing on Tax Invoice rows. Below the threshold, those fields may legitimately be absent on the document; above it, they are expected and a missing cell is a real signal.

A simplified tax invoice or a cash-register receipt can support an input-tax claim, within limits. IRAS allows a GST-registered business to claim input tax on a simplified tax invoice or a machine-printed receipt for supplies up to S$1,000 including GST, provided the document carries the supplier's name, the supplier's GST registration number, the date, a description of the goods or services, and the GST amount or a statement that GST is included. Two practical consequences land in the spreadsheet. First, a simplified receipt above S$1,000 cannot be relied on for an input-tax claim, so the row needs to flag for follow-up so the bookkeeper can request a full tax invoice. Second, GST charged by an apparently unregistered supplier is not claimable; if a row carries a GST amount but no supplier GST registration number, the input-tax claim against that row should not go forward without verification.

The standard rate is 9%. The GST rate column captures what the document states; the GST amount column captures the figure on the document. Where a row's stated GST amount does not reconcile to 9% of the net amount within rounding tolerance, the spreadsheet flags rather than overwrites. Some documents legitimately show a different rate (zero-rated supplies, exempt supplies); the flag exists to surface those for classification, not to assume an extraction error. The intake never silently corrects a number on the source document.

Recordkeeping retention is five years, and the spreadsheet is an index, not a replacement. The five-year obligation set out in the opening shapes the source-file column more than any other rule. Every row carries a reference back to the original PDF, scan, or photo, and the document number is preserved verbatim, because the obligation runs against the underlying records (soft and electronic copies of tax invoices are acceptable to IRAS provided controls are in place), and the spreadsheet's job is to make the auditable chain navigable on demand. A row whose source-file reference has gone stale because the underlying file was moved, renamed, or deleted is, for retention purposes, no longer a reliable record.

What the spreadsheet does not do. It does not adjudicate whether a particular purchase is GST-claimable, whether a supply is taxable or exempt, or whether a particular supplier should or should not have charged GST. Those decisions sit with the GST-trained reviewer working through the flagged rows. The spreadsheet's job is to make those decisions cheaply visible: every row that needs human judgment surfaces with the right flag, and every row that doesn't moves cleanly through to the ledger. Anything beyond that, including the deeper question of how the cleared rows feed Box 5 and Box 7 of the GST F5, belongs to the close cycle described later.

Retail-Specific Operational Rules: Outlets, Payment Mix, and Delivery Matching

The schema and the IRAS rules cover the regulatory shape of the spreadsheet. Three more rules sit on top, and they are the ones that distinguish retail intake from generic AP intake: outlet capture, payment-status capture, and delivery-quantity reconciliation. Each one earns its own column, and each one has a small set of decisions baked in that the bookkeeper does not have to make again per row.

Outlet capture for multi-store retailers. A retailer running more than one storefront needs the per-store cut of purchasing for cost analysis, stock reconciliation, and outlet-level P&L. The outlet column gets populated wherever the document carries it: a delivery address showing the receiving store, a POS receipt header naming the outlet, a store reference printed on a supplier tax invoice. Where the document does not show an outlet, the cell stays empty. Inferring an outlet from the supplier or the delivery date is not the spreadsheet's job; an empty outlet cell on a row that should have one is a flag, not a placeholder. The same applies when the goal is to extract Singapore POS receipts and supplier invoices to Excel as one workflow, where the POS-side outlet is on the receipt, the supplier-side outlet (where shown) is on the delivery address, and both populate the same column.

Payment status across POS, cash, and account. A POS receipt almost always carries an explicit payment line: cash, card, NETS, PayNow, contactless. A supplier tax invoice issued for goods delivered on account typically carries no payment line, because settlement runs through the AP cycle days or weeks later. A delivery note carries no payment information at all. The payment-status column captures what the document states verbatim ("PayNow", "NETS", "Cash", "Card", or whatever is printed). Rows whose source document does not state payment are left as a deliberate placeholder (account-or-pending), reconciled later when the AP run posts settlement, not guessed at intake. Inferring a payment status from anything other than the document text introduces noise into the column that the bookkeeper would have to remove.

Delivery-quantity vs invoice-quantity matching. The matched invoice/reference number column is the join key. When a delivery note for a supplier and the matching invoice from the same supplier both land in the batch, the bookkeeper can compare the quantity columns directly. A reconciled match is silent, and the row goes through. A mismatch is an operational signal: short delivery, partial shipment, supplier billing error, or an invoice that has rolled multiple deliveries into a single line. The next section specifies the flag that fires; the surface here is that the column structure makes the comparison possible without bolting on a separate reconciliation worksheet.

Receipt-only purchases that need follow-up for input tax. Where a simplified receipt sits above S$1,000 and the business intends to claim input tax against it, the row needs a full tax invoice from the supplier. This is a retail-specific reality because corporate purchasing on supplier accounts produces full tax invoices by default, whereas store-counter purchases (a sales associate buying packaging supplies on a corporate card, a manager picking up cleaning supplies in cash) often produce only the till receipt. Identifying these rows at intake, rather than at GST close when the F5 reconciliation surfaces the gap, is what stops the cleanup compounding.

Adjacent verticals and where to read deeper. The Singapore F&B supplier-invoice workflow shares most of these rules. F&B operators run multiple outlets, mix POS and supplier-account purchasing, and receive delivery notes that need matching against invoices from the same suppliers retail buys from (cleaning, packaging, beverages, sundries). Teams whose batch is heavily F&B can read the Singapore F&B supplier invoice GST and UEN workflow for the hospitality cut of the same intake, then come back to the unified column set here for the mixed retail batch.

Review-Flag Triggers: Catching Gaps Before Posting

The review-flag column is what makes this Singapore retail bookkeeping receipts invoices spreadsheet usable as a working process rather than a static layout. Each trigger produces a distinct flag value the bookkeeper can sort the column by, work through in batches, and clear before any row moves to the ledger or feeds the next quarter's GST F5.

The triggers, by name:

• MISSING_UEN_TAX_INVOICE. The row is tagged Tax Invoice but the supplier UEN column is empty. Either the document is not a valid full tax invoice (in which case the document type is wrong and the row should be re-tagged Simplified Receipt) or the UEN was missed at extraction (in which case the source file needs a re-read). Either way the row cannot move forward as a Tax Invoice without resolution.
• GST_CHARGED_NO_REGISTRATION. The row carries a GST amount but no supplier GST registration number. A supplier without GST registration is not entitled to charge GST; an apparent GST line on such a document is either a mis-reading at extraction or a real billing problem that needs to go back to the supplier. Either way, the input-tax claim against the row does not go forward in this state.
• MISSING_DOCUMENT_NUMBER. A Tax Invoice or Simplified Receipt row with no invoice or receipt number, or a Delivery Note row with no delivery-note number. The audit chain back to the source document depends on the document number, and a row without one breaks the five-year recordkeeping retrievability the schema exists to preserve.
• SIMPLIFIED_RECEIPT_OVER_THRESHOLD. The document type is Simplified Receipt but the gross total exceeds S$1,000. IRAS expects a full tax invoice at this level; the row needs follow-up with the supplier before any input-tax claim, and may need re-tagging once the full tax invoice arrives.
• GST_RATE_INCONSISTENT. The stated GST amount does not reconcile to 9% of the net amount within rounding tolerance. The row may legitimately be zero-rated, exempt, or carry a partial-credit treatment, so the flag exists for classification, not assumption. Any silent overwrite of the document figure here would corrupt the audit chain.
• UNMATCHED_DELIVERY_NOTE. A Delivery Note row whose matched invoice/reference number column is empty, or whose stated reference does not match any invoice number anywhere else in the batch. Either the matching invoice has not arrived yet (in which case the flag clears when the next batch lands) or the reference is misprinted on one of the documents and needs supplier follow-up.
• DELIVERY_QUANTITY_MISMATCH. A Delivery Note row whose quantity does not match the corresponding invoice line for the same matched reference. Short delivery, partial shipment, or supplier billing error; the row stays flagged until the operational reason is recorded against it.
• RECEIPT_FOR_INPUT_TAX_FOLLOWUP. A Simplified Receipt the bookkeeper has marked for input-tax claim where the document type does not by itself support the claim, typically a sub-S$1,000 receipt missing the supplier's GST registration number, where the supplier is in fact registered and a corrected document or a full tax invoice would unlock the claim.

A bookkeeper working through these flags in order (UEN problems first, then GST registration and rate problems, then document-number gaps, then delivery and threshold issues) clears the spreadsheet faster than working row by row, because each flag has the same fix pattern across rows that share it.

Where the cleared rows go next. Two downstream workflows pick up from here. When the UEN or GST-registration flags fire, the resolution is to verify a supplier's UEN and GST registration before paying; the dedicated guide walks through the BizFile and IRAS lookups that confirm whether the supplier is registered, whether the UEN matches the trading name on the document, and whether the GST registration is current. Once the supplier checks are clean and the spreadsheet is flag-free for the period, the same dataset becomes the input to the GST F5 quarterly close: the rows tagged Tax Invoice and Simplified Receipt with valid GST registration sum into Box 5 (total value of taxable purchases) and their GST amounts sum into Box 7 (input tax). The fuller workflow on how to reconcile the GST F5 Box 5 and Box 7 from supplier invoices covers the close-side mechanics; the intake spreadsheet's job is to deliver a clean, flag-free dataset to that step.

Running the Mixed Batch: Prompt-Based Extraction Without Per-Supplier Templates

The schema, the conditional rules, and the review-flag triggers all reduce to one practical question: how does the bookkeeper actually run the week's pile against this design without building a parsing pipeline or configuring a template per supplier? The answer is to convert mixed Singapore retail purchase documents to Excel as a single prompt-driven extraction job. Every supplier tax invoice PDF, every simplified receipt scan, every phone photo of a till slip, every delivery note that came in separately, uploaded together and processed against one prompt that defines the unified column set, the per-document-type conditional rules, and the review-flag triggers in natural language.

This is what AI-powered invoice and receipt data extraction does for the mixed Singapore retail batch: supplier tax invoices, simplified receipts, and delivery notes processed in a single job, no per-supplier templates, no rules engine to configure beforehand, and the same prompt re-running next week against next week's batch. The interaction model is a single prompt field with a file upload area (the pattern anyone using a modern AI tool already recognises), except the output is a structured Excel, CSV, or JSON file with one row per document and a reference back to the source file and page number for every row. Up to 6,000 files per batch and individual PDFs up to 5,000 pages mean a month of mixed retail purchasing fits comfortably in one job; saving the prompt to the prompt library means next month's batch reuses the same logic without rebuilding it.

The prompt itself is a goal-oriented intro followed by the field-and-rule list. Adapted from the patterns the product's prompt library supports:

I'm processing a mixed Singapore retail batch of supplier tax invoices, simplified receipts, and delivery notes for bookkeeping and GST capture. One row per document.

Extract:

• Source File (auto-populated)
• Document Type (classify as Tax Invoice, Simplified Receipt, or Delivery Note)
• Supplier Name
• Supplier UEN (extract if present)
• Supplier GST Registration Number (extract if present)
• Document Date (YYYY-MM-DD)
• Invoice or Receipt Number (alphanumeric)
• Delivery Note Number (alphanumeric)
• Item Description (join multiple line items with semicolons)
• SKU/Product Code
• Quantity
• Unit Price
• Net Amount (pre-GST)
• GST Amount (if no GST is present use 0)
• GST Rate (use Excel type percentage)
• Gross Total
• Payment Status (extract verbatim if shown, otherwise leave empty)
• Outlet/Location (extract from delivery address or store reference if shown)
• Delivery Date (delivery notes only)
• Matched Invoice/Reference Number
• Review Flag

Rules:

• For Delivery Note rows, set GST Amount and GST Rate to 0 and leave price columns empty.
• For Simplified Receipt rows where Gross Total exceeds S$1,000, set Review Flag to SIMPLIFIED_RECEIPT_OVER_THRESHOLD.
• For Tax Invoice rows missing Supplier UEN, set Review Flag to MISSING_UEN_TAX_INVOICE.
• For any row with GST Amount above 0 but no Supplier GST Registration Number, set Review Flag to GST_CHARGED_NO_REGISTRATION.
• For Delivery Note rows with no Matched Invoice/Reference Number, set Review Flag to UNMATCHED_DELIVERY_NOTE.
• Skip any pages that are email cover sheets, remittance advices, or summary pages.

The detail above is what goes into the prompt the first time. Once it produces a clean run on a representative batch, it gets saved and reused; the next month's intake is the same job, run against the new files, with the same conditional logic and the same review-flag values populating the column. Adjustments are made to the saved prompt rather than to per-supplier templates that proliferate over time.

The audit chain stays intact across all of this. Every row carries the source file and page number, which means every flagged exception lands with a direct route back to the original document, and every cleared row keeps the reference that satisfies the five-year retention obligation.