You've built your entire client book in Notion. Contacts, projects, payment history, custom billing notes—it's all there. Then you decide to switch to real invoicing software. You export your contact database, hit import, and watch the data land in your new platform. But something's wrong. Half the fields are gone. Your tax ID column is blank. Billing address and shipping address got merged into one. Payment terms vanished. Custom billing schedules disappeared. This isn't a bug in your new software. It's what happens when you export from a relational database (Notion) into a platform that wasn't built to receive that structure. Notion's flexibility becomes a liability on export. Fields orphan. Relationships flatten. Custom metadata evaporates. I'm going to show you exactly which eight fields disappear, why, and the fastest way to recover each one—without manually re-entering everything from scratch. Why Notion exports break invoicing data Notion stores data in a way that's infinitely flexible but structurally incompatible with invoicing systems. A Notion contact record can have 50 custom columns, nested related records, formula fields, and rollups. When you export as CSV, Notion flattens all of that into columns. But invoicing software—whether it's Xero, Wave, QuickBooks, or even a platform built for it —expects a specific schema. It has slots for: A primary billing address (with street, city, postal code, country) An optional shipping address (same structure) Standard payment terms (Net 30, Net 60, Due on receipt) A tax ID field (GST, NPWP, SST, BRN) Default payment method Currency Notion has none of these slots. Instead, it gives you a blank canvas. So when you export, Notion outputs everything as flat text columns. Your invoicing software imports those columns, can't map them to its schema, and leaves them orphaned in a generic "notes" field or drops them entirely. The eight fields that orphan on export 1. Tax ID (GST, NPWP, SST, BRN) In Notion, you probably stored this in a text field called "Tax ID" or "GST Number" or just shoved it in the company name. On export, invoicing software looks for a field called tax_id , vat_id , or gst_number . If your Notion column was named anything else—or if the data was mixed with other company info—it gets ignored. Recovery: Before export, create a dedicated Notion column titled exactly "Tax ID" (or check your invoicing platform's import template for the exact field name it expects). Copy all existing tax IDs into that column. If they're scattered across company names or notes, use a formula or manual sort to consolidate them. Then map this column explicitly during import. 2. Billing address vs. shipping address (address splitting) Notion's address field is a single text blob. You might have written "123 Main St, Suite 500, Toronto, ON M1A 1A1" all in one cell. On import, invoicing software expects this to be parsed into street, city, province, postal code, country—and separately expects an optional shipping address in the same structure. Notion exports the blob as one column. Your invoicing software can't split it. Result: the address lands in the billing field, shipping remains blank, and postal code data is lost. Recovery: In Notion, before export, create separate columns: Billing Street, Billing City, Billing Province, Billing Postal, Billing Country. Do the same for shipping. Then parse your existing address blob into these columns using either Notion formulas (if the data is consistent enough) or a quick script via no-code automation that splits on comma. This takes 30 minutes for 100 contacts. Then map each Notion column to the corresponding invoicing platform field during import. 3. Payment terms (Net 30, Net 60, Due on receipt) Notion stores payment terms as text—maybe "Net 30" or "Due on receipt" or "30 days" or even "1 month." Invoicing software has a closed list of payment term codes: NET_30 , NET_60 , DUE_ON_RECEIPT , etc. Your Notion export includes the text, but the invoicing software can't match "30 days" to its NET_30 code, so it defaults to DUE_ON_RECEIPT or leaves the field empty. Recovery: Create a lookup table in Notion: Notion text values on the left ("30 days", "Net 30", "1 month"), invoicing platform codes on the right ( NET_30 ). Use a formula column to map each client's existing payment term text to the correct code. Export that formula result. On import, use that column and explicitly set it as the payment terms field. 4. Custom billing schedule or cycle (annual, quarterly, monthly, one-off) You might have a Notion column that says "Invoiced quarterly" or "Annual retainer" or "Per-project." This data is descriptive and free-form. Invoicing software either doesn't have a field for it at all, or it has a fixed set of billing cycle options (weekly, biweekly, monthly, quarterly, annually). Your custom text orphans because there's nowhere to map it. Recovery: In your invoicing platform, check if it has a billing cycle or frequency field. If it d