A Singapore InvoiceNow XML follows the PINT-SG specification, the local Peppol profile of Peppol BIS Billing 3.0, and is structured as an OASIS UBL 2.1 XML document. To convert Singapore InvoiceNow XML to Excel, you map the UBL elements inside the file to the plain-English column names you already use in your supplier-invoice register: invoice number, issue date, supplier name, supplier UEN, supplier GST registration number, line description, quantity, unit price, line total ex-GST, GST rate code, GST amount, currency, totals.
According to OpenPeppol's PINT-SG specification, PINT-SG, the Peppol International model for Singapore, uses the OASIS UBL 2.1 XML format on a syntactical level. So every conversion question reduces to the same thing: which UBL element holds which value, and what should the Excel column be called.
There are two output shapes worth knowing before you start. Header-row-per-invoice produces one row per invoice with the totals collapsed into header columns. It suits month-end review against the GL, supplier-spend pivots, and management views. Line-item-per-row produces one row per cac:InvoiceLine with the header fields repeated on every row. It suits GL posting where each line carries its own account code and the GST F5 working papers where rates vary line by line. The same set of XMLs produces either shape depending on what you ask for; many bookkeepers produce both for the same month.
A few specifics for grounding. The PINT-SG customisation ID is urn:peppol:pint:billing-1@sg-1 and the profile ID is urn:peppol:bis:billing. Document type code 380 is an invoice; 381 is a credit note. You will see these values in every PINT-SG file.
Scope. This article walks the conversion workflow only. Mandate timeline, phased rollout, and which suppliers are required to issue PINT-SG by when sit in Singapore InvoiceNow mandate timeline and PINT-SG context. Validating an XML for input GST claim is a sibling intent. Setting up Xero or QuickBooks to receive InvoiceNow is another, walked through in receiving InvoiceNow Peppol invoices natively in Xero, QuickBooks, and MYOB. The rest of this piece assumes you have files in your access-point folder and you want them in a spreadsheet.
From PINT-SG XML elements to bookkeeper columns
The reference table below is the artefact most readers will return to. It maps every PINT-SG (UBL 2.1) element a Singapore bookkeeper actually cares about to the plain-English column name you would put in a supplier-invoice register. One row per element, one column heading per row. If you only read one section, read this one.
A small navigation note before the tables. UBL uses two namespace prefixes: cbc: for Common Basic Components, which carry single field values, and cac: for Common Aggregate Components, which are nested blocks containing other elements. You do not need to memorise this. Treat cbc: as "single field" and cac: as "nested block" and the structure becomes easy to navigate.
Header fields
| PINT-SG element | Excel column | Note |
|---|---|---|
cbc:ID | Invoice Number | |
cbc:IssueDate | Issue Date | |
cbc:DueDate | Due Date | |
cbc:InvoiceTypeCode | Document Type | Code 380 is an invoice, 381 is a credit note. |
cbc:DocumentCurrencyCode | Currency | Usually SGD; render as S$ in management views. |
cac:AccountingSupplierParty/cac:Party/cbc:EndpointID (with @schemeID="0195") | Supplier UEN / Peppol ID | The schemeID="0195" attribute confirms the participant identifier is a Singapore UEN. |
cac:AccountingSupplierParty/cac:Party/cac:PartyName/cbc:Name | Supplier Name | |
cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID | Supplier GST Registration Number | Where the supplier is GST-registered; absent for non-registered suppliers. |
cac:AccountingCustomerParty/cac:Party/cbc:EndpointID | Buyer UEN / Peppol ID | Your own organisation in the receiving direction. |
cac:AccountingCustomerParty/cac:Party/cac:PartyName/cbc:Name | Buyer Name | |
cac:PaymentTerms/cbc:Note | Payment Terms | Free-text; varies by supplier. |
Line-item fields
Each invoice carries one or more cac:InvoiceLine blocks. The line-item shape repeats these as rows.
| PINT-SG element | Excel column | Note |
|---|---|---|
cac:InvoiceLine/cbc:ID | Line Number | |
cac:InvoiceLine/cac:Item/cbc:Name and cac:Item/cbc:Description | Item Name and Description | Some suppliers populate only one. |
cac:InvoiceLine/cbc:InvoicedQuantity (with unitCode) | Quantity | The unitCode attribute carries the unit of measure: EA (each), KGM (kilograms), HUR (hours), and so on. |
cac:InvoiceLine/cac:Price/cbc:PriceAmount | Unit Price | |
cac:InvoiceLine/cbc:LineExtensionAmount | Line Total ex-GST | |
cac:InvoiceLine/cac:Item/cac:ClassifiedTaxCategory/cbc:ID | GST Rate Code | One of SR, SR-8, ZR, ES, OS, IM. See the rate-code key below. |
cac:InvoiceLine/cac:Item/cac:ClassifiedTaxCategory/cbc:Percent | GST Rate (%) | The rate value applied to the line. |
Totals
The cac:TaxTotal and cac:LegalMonetaryTotal blocks at the foot of the document carry the invoice-level numbers.
| PINT-SG element | Excel column | Note |
|---|---|---|
cac:TaxTotal/cbc:TaxAmount | Total GST | |
cac:LegalMonetaryTotal/cbc:LineExtensionAmount | Total ex-GST | Sum of all line LineExtensionAmount values. |
cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount | Total Tax-Exclusive | Net amount before any GST. |
cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount | Total inc-GST | Net plus GST. |
cac:LegalMonetaryTotal/cbc:PayableAmount | Amount Payable | What the buyer settles; usually equal to Total inc-GST after any prepaid amounts. |
GST rate codes you will see
The ClassifiedTaxCategory/cbc:ID value tells you how each line is treated for GST. There are six codes worth recognising:
- SR is standard-rated, currently 9 percent. The bulk of taxable purchases.
- SR-8 is the legacy 8 percent standard-rated code from before the 2024 rate change. You may still see it on credit notes or late-arriving invoices that relate to pre-change supplies; treat as historical.
- ZR is zero-rated. Taxable but the rate is 0 percent (typical for exports of services).
- ES is exempt. Outside the GST system entirely (financial services, residential property).
- OS is out of scope. Not a Singapore GST supply.
- IM is import. Imported goods or services where GST treatment depends on the import mechanism.
The codes are the pivot anchor for the F5 working papers in Section 6. Get them right in the spreadsheet and the Box 5 / Box 7 tabulation falls out of a filter.
This is a translation table, not an XML tutorial. The next sections assume you will run the actual extraction with a tool, not by hand.
Two output shapes: header-row-per-invoice and line-item-per-row
The same set of PINT-SG XMLs can produce either of two spreadsheet shapes. The choice is a workflow decision, not a property of the source files. Pick the shape that fits what you are about to do with the spreadsheet.
Header-row-per-invoice is one row per invoice, totals collapsed. The columns are the header fields from Section 2 (Invoice Number, Issue Date, Document Type, Supplier Name, Supplier UEN, Supplier GST Registration Number, Buyer Name, Currency, Payment Terms) plus the four invoice-level totals (Total ex-GST, Total GST, Total inc-GST, Amount Payable). No line-item detail. This is the shape you want for:
- Month-end review against the GL supplier-AP control account.
- Supplier-spend pivots by UEN for a quarter or a year.
- A controller's payment-authorisation worksheet, where line-by-line detail would obscure the decision.
- Management-reporting views that summarise spend by supplier.
Line-item-per-row is one row per cac:InvoiceLine, with the header fields repeated on every line. Quantity, Unit Price, Line Total ex-GST, GST Rate Code, and GST Rate (%) become the differentiating columns; Invoice Number, Issue Date, Supplier Name, and Supplier UEN repeat down the rows so each line stays attributable to its invoice. This is the shape you want when you need to map PINT-SG line items to Excel rows for:
- GL posting where each line carries its own account code or cost-centre.
- GST F5 working papers where Box 5 (taxable purchases) and Box 7 (input tax) require line-by-line treatment because rates vary within a single invoice.
- GST rate-code analysis: filter the rows by SR, SR-8, ZR, ES, OS, or IM and the spreadsheet tabulates Box 5 and Box 7 directly from the filtered totals.
- Spotting line-level coding errors that header totals would mask, such as a single SR line buried inside an otherwise-ZR export invoice.
The shape choice is not exclusive. A typical month-end produces both: header-row for the close meeting and the controller's review, line-item-per-row for posting to the GL and feeding the quarterly F5 working papers. A partner reviewing the close will often pull both as separate tabs in the same workbook. Producing both does not mean running the conversion twice on the source files; it means asking for two output shapes from the same input batch.
For most SG bookkeepers the practical rule is simpler than it sounds. If the destination is a journal entry or a tax return, line-item-per-row. If the destination is a review screen or a pivot, header-row-per-invoice. If the destination is "I don't know yet, I want to see the month", produce both.
Converting a batch of PINT-SG XMLs in one pass
A single PINT-SG XML is a thirty-second job. The work that defines a Singapore bookkeeper's month is the batch: fifty to two hundred XMLs across thirty to fifty suppliers, dropped into the access-point folder over the course of the month and waiting at close. Bulk PINT-SG XML to Excel batch is the workflow that needs to be quick, repeatable, and consistent.
The no-code path is short. Drop the folder of XMLs into the conversion tool. Write a prompt that names the columns you want using the bookkeeper-facing names from Section 2 (Invoice Number, Issue Date, Supplier Name, Supplier UEN, Supplier GST Registration Number, and so on) and that says which output shape you want. Run it. Open the resulting Excel or CSV.
If you searched for an InvoiceNow XML viewer for accountants and landed here, the distinction is worth keeping straight. A viewer renders one XML readably on screen so you can confirm what it contains. A converter produces a working spreadsheet across a folder. Both are useful, but they solve different problems. At month-end, when the question is "what did we receive from suppliers this month and does it tie to the GL", a viewer reaches its limit at the first batch. There is also a column-naming problem. Most generic Peppol viewers and online converters output raw cbc: and cac: element names as headers, which leaves you to rename every column by hand against the dictionary in Section 2 before the spreadsheet is usable. A prompt-driven tool lets you specify the SG-facing column names directly in the prompt, so the export lands with "Supplier UEN" rather than cac:AccountingSupplierParty/cac:Party/cbc:EndpointID.
AI invoice data extraction is built around exactly this batch-and-prompt pattern. The interface is a prompt field and a file-upload area, the same interaction model as ChatGPT. There are no templates to configure and no setup wizards. You write the prompt once, naming the columns in your supplier-invoice register and the output shape (header-row-per-invoice or line-item-per-row), and you save it to your prompt library. Every month-end you reapply the saved prompt to the new folder and the conversion runs identically across the batch. The same workflow handles a single PINT-SG XML or up to 6,000 files in a single batch, which is well above any plausible SG SMB or external-firm month-end volume. Output is delivered as Excel, CSV, or JSON.
The repeatable saved prompt matters more than it sounds. Month-end reconciliation depends on consistency: the same column names in the same order, every month, so last month's pivot template still works on this month's data and the partner reviewing close is reading the same shape they reviewed last quarter. The prompt becomes the standard, and the standard becomes the working paper format.
Hybrid PDF and PINT-SG corpus: one workflow, two source formats
The InvoiceNow mandate is phased. The full effect arrives in 2031, which means most SG SMBs and external accounting firms will spend the next several years processing a mixed supplier base: some suppliers issuing PINT-SG XML through the access point, others still emailing PDF invoices the way they always have. Any conversion approach that only handles XML solves half the problem and leaves the bookkeeper switching contexts between source formats every month.
The workable answer is to consolidate PDF and PINT-SG invoices Singapore-side into the same column set. Define the column list once (Invoice Number, Issue Date, Supplier Name, Supplier UEN, Supplier GST Registration Number, line description, quantity, line total ex-GST, GST rate code, and so on) and run both formats into it. The output is one consolidated month-end spreadsheet, not two.
A concrete shape: a forty-supplier base where eighteen are on InvoiceNow and twenty-two are still on PDF produces a single supplier-invoice register for the month. The pivots that summarise spend by UEN, the GL posting, the F5 working papers, the partner-review screen, none of them care about source format once the data is in the same shape. The bookkeeper writes the prompt once and the same prompt works against a folder of mixed PDFs and PINT-SG XMLs.
This is the natural position of a prompt-driven extraction tool. Source-format-specific converters tie their output to the schema of the input format, which is why a generic Peppol viewer outputs cbc: element names and a generic PDF parser outputs whatever the supplier put on the invoice. A prompt that defines the column set decouples the output shape from the source schema. The PDF cousin to this article walks the equivalent workflow on the PDF side: see convert PDF invoices to Excel for the same conversion-pattern applied to the format that will dominate the SG corpus through the rollout window.
Two practical notes on running the mixed corpus. First, keep PINT-SG XMLs and PDFs in separate sub-folders inside the month folder, even when the conversion handles both. The XMLs are your record of original entry under IRAS retention rules; mixing them with PDFs in the same archive directory makes future audit-trail work harder. Second, suppliers in transition often send both: a PINT-SG XML through the access point and a courtesy PDF by email. Treat the XML as primary and the PDF as duplicate; do not extract both into the same register or you will double-count the invoice in the spreadsheet.
What the spreadsheet enables: month-end review, GL posting, and F5 prep
The conversion is not the destination. The spreadsheet exists so the bookkeeper can do specific downstream work. Each downstream destination has a slightly different set of demands on the spreadsheet, and the choices made earlier (which columns, which output shape, saved prompt or one-off) pay back here.
Month-end review against the GL. Sum Total inc-GST by supplier and tie the totals to the supplier-AP control account. The header-row shape is the working tool for this; one row per invoice means the sum-by-supplier pivot lands in three clicks. Outliers (a supplier whose total has doubled, an invoice with a Document Type of 381 mis-coded as a regular invoice) surface during the tie-out, and you fix them before posting rather than after.
Supplier-spend pivots by UEN. The UEN column is the clean key for spend analysis. Supplier names drift: "ABC Supplies Pte Ltd", "ABC Supplies", "ABC", and the same supplier with a DBA name may all appear across a year of invoices. The UEN does not drift. Pivot on UEN and the deduplication is automatic; pivot on Supplier Name and you spend twenty minutes consolidating spelling variants. The same UEN column is what supplier verification keys off, which is the topic of Singapore supplier invoice extraction with GST and UEN fields for the F&B-specific PDF corpus.
GST F5 working papers. Box 5 (taxable purchases, the value of standard-rated and zero-rated purchases) and Box 7 (input tax, the GST claimable on those purchases) are the bookkeeper's quarterly preoccupation. The line-item-per-row shape filtered by GST Rate Code is the direct prep. Filter to SR and SR-8 (legacy 8 percent lines on credit notes or late-arriving invoices) and the sum of Line Total ex-GST plus the sum of GST Amount feeds Box 5 and Box 7 respectively. Add ZR for completeness in Box 5. Drop ES and OS from the F5 calculation entirely. The filter-and-sum approach makes the F5 working papers reproducible: the same prompt run on the same quarter's XMLs produces the same numbers, every time. For the full quarterly build — input-tax eligibility gates, import-permit handling, the 9/109 maths on inclusive amounts, and F7 corrections — see building Box 5 and Box 7 from supplier invoices for the IRAS GST F5.
GL posting. Line-item-per-row carries enough granularity for line-level account coding. Each row has its own GST Rate Code, which drives the input-tax journal split, and its own description, which informs the expense account choice. Coding by line rather than by invoice is what SG accounting partners ask for when the invoice mixes capex and opex on the same document.
Audit trail. A working point that gets confused regularly: the spreadsheet is a working paper, not the record of original entry. The PINT-SG XML is the record. IRAS requires invoice records to be retained for five years, and the source XML is what satisfies that requirement. The spreadsheet supports your review and posting work; the XML is what you produce if IRAS asks. Keep the XMLs archived (by month, by supplier, however your filing system runs) even after the spreadsheet is reconciled and the journal is posted.
Recurring monthly export to CSV. This is the saved-prompt workflow from Section 4, run on a schedule: same column set, same output shape, same prompt, fresh data. CSV is the right output where downstream consumers (a GL system import, a working-paper template that reads CSV) prefer it; XLSX is the right output where the bookkeeper or partner is going to open and pivot directly. The InvoiceNow XML to CSV bookkeeping flow is exactly this. The choice between CSV and XLSX is the bookkeeper's, and the prompt-driven tool will produce either from the same source folder. Once the prompt is saved, the month-end Singapore InvoiceNow batch export is a one-click recurring task.
Developer paths: XSLT, Python, and Excel's built-in XML import
A bookkeeper-reader does not need to write any of these themselves. The point of this section is enough vocabulary to brief an internal IT colleague or an external integration partner on which approach fits which scenario. A developer-reader scoping a small in-house build will recognise the framing.
XSLT. A stylesheet transformation written against the UBL 2.1 schema can render a PINT-SG XML into a tabular output, with CSV being the typical landing format. XSLT fits integration teams that already own an XSLT toolchain or that want a pure-XML pipeline with no prompt-driven layer between source and output. The brittleness shows when supplier files vary in their use of optional elements: an XSLT that assumes cac:PaymentTerms/cbc:Note is always present breaks the moment a supplier omits it, and the team ends up maintaining a stylesheet that grows defensive checks over time.
Python with lxml or xml.etree.ElementTree, plus openpyxl. Read each XML, walk the elements named in Section 2's dictionary, append rows, save the workbook. Forty lines of Python gets a working header-row converter; another twenty handles the line-item shape. Python fits moderate-volume scenarios with custom logic that does not belong in the conversion tool itself: classifying GST rate codes into in-house bookkeeping categories on the fly, enriching with a vendor-master lookup keyed on UEN, splitting credit notes into a separate output. A small finance-engineering team can run a Python pipeline against a watched folder and have the conversion happen automatically as XMLs arrive.
Excel's built-in XML map import. From the Developer tab, Source, XML Maps, you can map the structure of an XML file onto a worksheet and import. It works on flat XML and falls down on UBL. The repeating cac:InvoiceLine blocks and the nested cac:Party hierarchies in PINT-SG are deeper than Excel's XML map handles cleanly, and what you get is usually a flattened view with merged cells where the line-item nesting collapses. Useful for inspecting one XML out of curiosity. Not a batch path.
The honest framing is that none of these is the bookkeeper's primary path. XSLT belongs in a structured pipeline managed by an integration team. Python belongs where custom logic justifies a small in-house build. The XML map belongs in the realm of one-off inspection. The conversation a bookkeeper has with their IT colleague or external integration partner is about which of these (or a prompt-driven tool, where the no-code path is preferred) suits the volume and the customisation the firm actually needs.
A related but distinct workflow worth naming: the reverse direction, where upstream PDFs or other inputs are converted into Peppol UBL XML for outbound issuance. That is its own conversion problem and a separate set of trade-offs. See convert PDF invoices into Peppol UBL e-invoices for that workflow.
Extract invoice data to Excel with natural language prompts
Upload your invoices, describe what you need in plain language, and download clean, structured spreadsheets. No templates, no complex configuration.
Related Articles
Explore adjacent guides and reference articles on this topic.
Receive Singapore InvoiceNow Invoices in Xero & QuickBooks
Receive Singapore InvoiceNow PINT-SG invoices in Xero, QuickBooks, and MYOB: pick an IMDA-accredited access point, register your Peppol ID, run draft bills.
Singapore InvoiceNow E-Invoicing Mandate: Complete Guide
Vendor-neutral guide to Singapore's InvoiceNow mandate. Covers the phased timeline, 5-corner Peppol model, PINT-SG format, subsidies, and preparation steps.
Reconcile Singapore GST F5: Box 5 & Box 7 From AP Invoices
Singapore GST F5 from supplier invoices: input-tax eligibility gate, Box 5 / Box 7 build, import-permit and 9/109 maths, F7 corrections, IRAS working papers.