Imports with AI

AI assistants are genuinely useful for validating a filled-in import template before you upload it. Given the detailed rules the importer enforces — required fields, sign conventions, cross-field dependencies, date formats, and the reconciliation between transaction totals and the trial balance — running a validation prompt against your file can catch a significant number of problems before they cause an upload failure or, worse, silent bad data in the system.

It may also be able to help with reformatting data from a previous system into the correct column layout — though results vary significantly depending on how clean and consistent the source data is. Treat any AI-converted output as a first draft that still needs careful review, not a finished file ready for upload.

That said, it is worth being clear about what AI cannot do. It cannot tell you whether a balance is genuinely outstanding, whether a supplier invoice has already been paid, how to handle units that changed ownership mid-year, or whether figures from a previous agent’s export can be trusted. It will produce plausible-looking output on all of these — you still need to review everything carefully.

The prompts on this page are intended to save time on the mechanical parts of migration preparation, not to replace the professional judgement involved in a clean handover.

Caution

At the end of the day, you are responsible for the correctness and accuracy of the data that gets imported. AI-assisted validation reduces the risk of format errors, but it cannot verify that the underlying figures are right. Always reconcile against your source records before submitting an import.

Which AI assistant to use

The three main options are Claude (Anthropic), ChatGPT (OpenAI), and Gemini (Google). All three can read uploaded Excel files and handle structured data tasks.

For validating a filled-in template (Prompt 1 below), Claude is the strongest choice. It follows multi-rule instructions very reliably and handles complex cross-field validation well.

For converting messy source data into template format (Prompt 2 below), ChatGPT Plus is particularly effective because it includes a built-in Code Interpreter that can run Python directly against your spreadsheet — useful when column names are inconsistent or data needs substantial reshaping.

Gemini Advanced is a good alternative if you already work in Google Workspace, as it can access Google Drive files directly.

For a large migration — hundreds of units, multiple years of transactions — a paid subscription on at least one of these services is strongly recommended. Free tiers have tight usage limits and may silently truncate large files.

Caution

Before uploading any personal data (member names, emails, financial records) to an AI service, read the GDPR section below and ensure you have the OMC’s written authorisation.

---

What data you need to prepare

A full migration typically requires six categories of data. You do not always need all of them — but the goal is that after import the system accurately reflects who owns each unit, what each owner owes, what you owe each supplier, and what cash is in each bank account.

1. Units The complete list of properties in the development — unit names/numbers and addresses at minimum. Type, size, bedrooms, floor, and car spaces can be added now or later.

2. Contacts Owners, owner-occupiers, and residents linked to their units, with roles and effective dates where known. At minimum you need the current owners so that service charge statements can be issued.

3. Suppliers All suppliers, but at a minimum any supplier with an outstanding invoice balance at the start of your migration period. Without these, you cannot import the matching payment records or set an accurate creditors balance.

4. Service charge history (debtors) Enough charge and receipt history to explain the current balance on every unit account. The goal is that the net total of all imported service charge transactions matches the Debtors figure on your opening trial balance.

5. Purchase history (creditors) Enough purchase invoices and payments to explain any currently outstanding supplier balances. If an invoice was raised last year and is still unpaid, it needs to be in the system so the payment can be matched against it later. The goal is that the net total of imported purchase transactions matches the Creditors figure on your opening trial balance.

6. Opening trial balance with bank balances A snapshot of all general ledger account balances at the start of your first accounting period. This must include each bank account balance so that bank reconciliations are possible from day one. Total debits must equal total credits.

How much history to import

Importing the complete transaction history of every unit and supplier is rarely worth the effort and is usually where migrations become unwieldy. The practical target is the outstanding transactions as at the transfer date — not everything, just what is still open.

For both debtors and creditors, the best starting point is the aged receivables / aged payables report from the previous system as at the transfer date. This lists exactly the transactions that are still outstanding — typically a fraction of the full history — and is usually the right set of rows to import.

For debtors, importing the individual outstanding charges and credits means members can see their full statement online and understand exactly what they owe and why.

For creditors, importing the individual outstanding invoices means each one can be paid individually when the time comes — payments are matched against specific invoices rather than against a single unbreakable lump sum.

A single lump-sum opening balance per unit (e.g. “Arrears b/f”) or per supplier (e.g. “Opening Balance”) is always a safe fallback if the aged report is unavailable or too messy to work with cleanly.

In all cases, the trial balance provides the figures to reconcile against.

---

GDPR and data protection

Member names, email addresses, postal addresses, and financial records are personal data under GDPR (EU) 2016/679 and the Irish Data Protection Acts 1988–2018.

When you upload this data to an AI assistant, you are sending it to a third-party platform — typically operated by a US-based company. This constitutes a transfer of personal data outside the EEA, which requires a lawful basis under GDPR.

Key points:

• The OMC is the Data Controller. It decides the purpose and means of processing member data.
• The managing agent is a Data Processor, acting on the OMC’s written instruction.
• Anthropic (Claude), OpenAI (ChatGPT), and Google (Gemini) each operate under GDPR-compliant terms of service and do not use uploaded conversational data for model training in their paid tiers. However, data is processed on infrastructure that may be outside the EEA.
• The lawful basis for this processing is typically legitimate interest — the operational necessity of completing a system migration on behalf of the OMC.
• Individual member consent is not required for this type of data processing, provided the OMC has a legitimate interest and processes data proportionately.

This is general information, not legal advice

The above is a general overview only and should not be relied upon as legal advice. Every OMC’s circumstances are different. If you have any doubt about your obligations, speak to a solicitor or GDPR consultant before uploading any personal data to a third-party platform.

Before uploading any member or financial data, the managing agent should obtain written authorisation from the OMC. A suitable letter template is provided below.

Tip

It is recommended to anonymise personal data where possible before uploading to an AI platform. In practice, member names are often the key that links units, contacts, and transactions together, so wholesale anonymisation may not be practical — but replacing email addresses, phone numbers, and postal addresses with placeholders for early data-cleaning passes will reduce the amount of personal data processed unnecessarily.

OMC authorisation letter

The letter below may be adapted and signed by a director or company secretary of the OMC before any personal data is uploaded to an AI platform.

[OMC Company Name]
[Registered Address Line 1]
[Registered Address Line 2]
[Town / City, County, Eircode]

[Date]

Data Migration Authorisation, Risk Acknowledgement & Indemnity Letter

Re: Authorisation to Process All Accounting, Membership & Associated Data for System
    Migration Purposes

We, [OMC Company Name] (Company No. [XXXXXXX]), acting as Data Controller under GDPR
(EU) 2016/679 and the Irish Data Protection Acts 1988–2018, hereby authorise
[Your Company Name] ("the Processor") to access, process, clean, transform, and migrate
all accounting, membership, and associated personal data in our possession, regardless of
the source system, format, or media in which it is held. This includes, but is not limited
to, data held in spreadsheets, PDF documents, legacy software exports, paper records in
digital form, and any other format provided by our previous managing agent,
[Previous Agent Name], or any other prior agent or system.

1. Scope of Data Covered

The data covered by this authorisation includes all of the following, in any format or
source:

    (a) Debtor and creditor ledgers, transaction histories, and account balances
    (b) OMC member names, unit numbers, ownership details, and contact information
    (c) Service charge records, arrears, and payment histories
    (d) Supplier/creditor details and purchase records
    (e) Any other accounting, membership, or operational data provided in spreadsheets,
        PDFs, or other formats

2. Confirmations & Authorities

We confirm and agree to the following:

    1. We are the Data Controller of all data covered by this authorisation and have
       the legal authority to grant this permission.
    2. We authorise the use of third-party AI-assisted tools — including Anthropic's
       Claude platform — as reasonably necessary to clean, parse, transform, and format
       the data for migration purposes.
    3. We accept that as Data Controller, primary responsibility for the lawful
       processing of this data rests with us, and that our legal basis for this
       processing is legitimate interest, namely the operational necessity of completing
       a system migration on behalf of the OMC.
    4. We indemnify [Your Company Name] against any claims, losses, fines, or regulatory
       findings arising from this data migration, provided that [Your Company Name]
       handles the data in good faith, solely for the purposes stated herein, and takes
       reasonable care in its handling.
    5. We instruct that all data provided for migration purposes be securely deleted or
       destroyed by [Your Company Name] upon successful completion of the migration, and
       no later than [Target Deletion Date].

3. Risk Acknowledgements & GDPR Considerations

We acknowledge that we have been made aware of the following risks and considerations,
and that we accept responsibility for them as Data Controller:

(a) Potential Transfer of Data Outside the EU
    Anthropic's Claude platform is operated by Anthropic, PBC, a US-based company. While
    Anthropic operates under GDPR-compliant terms and does not retain conversational data
    between sessions, we acknowledge that data uploaded to the platform may be processed
    on infrastructure located outside the European Economic Area (EEA). We accept this
    risk and confirm that we have satisfied ourselves that this constitutes an appropriate
    transfer mechanism under Article 46 or Article 49(1)(b) GDPR, or alternatively we
    accept this as a one-time, operationally necessary transfer under Article 49(1)(c)
    GDPR.

(b) Member Personal Data — Consent & Lawful Basis
    The data to be migrated includes personal data relating to OMC members. Under GDPR,
    individual member consent is not required for this migration where the lawful basis
    is legitimate interest or contractual necessity. However, we confirm that:
    (i)  Our processing of member data for the purpose of managing the OMC's accounts and
         records constitutes a legitimate interest as Data Controller;
    (ii) A Legitimate Interests Assessment (LIA) has been or will be conducted if
         required;
    (iii) Members were, or will be, informed of any change of managing agent and the
          associated data transfer via appropriate notice, in accordance with Article
          13/14 GDPR obligations.

(c) Data Accuracy & Integrity
    We acknowledge that the data being provided for migration may be incomplete,
    inconsistent, or in non-standard formats. We accept responsibility for the accuracy
    and completeness of the source data and do not hold [Your Company Name] responsible
    for errors arising from deficiencies in the data as originally provided.

(d) Data Breach Responsibility
    In the event of a personal data breach arising from this migration process, we accept
    that, as Data Controller, we bear primary responsibility for notification to the Data
    Protection Commission (DPC) within 72 hours (where required under Article 33 GDPR)
    and to affected individuals where applicable under Article 34 GDPR. We acknowledge
    that [Your Company Name] is acting as Data Processor on our instruction and that
    breach liability rests with the Data Controller except where the Processor has acted
    negligently or outside the scope of this authorisation.

Signed on behalf of [OMC Company Name]:

Name:       ___________________________

Title:      Director / Company Secretary

Signature:  ___________________________

Date:       ___________________________

Important Notice: This letter does not constitute legal advice and has been prepared as a
working document only. The OMC and its officers are strongly encouraged to seek independent
legal advice from a solicitor experienced in GDPR and data protection law before signing,
particularly in relation to the transfer of member personal data outside the EEA and any
obligations to notify members. The indemnity in clause 2(iv) applies solely where
[Your Company Name] acts in good faith and within the scope described above.

---

Prompt 1 — Validate your filled-in template

Use this prompt once you have downloaded and filled in the OMC Excel setup template. Attach the .xlsx file to your AI chat message, then paste the prompt text.

The assistant will work through every sheet and flag rows that will fail on upload and rows that look suspicious. Take its output as a checklist — fix each issue in your Excel file, then re-run the prompt on the updated file before uploading.

I am attaching an Excel file — this is the OMC setup import template, partially or fully filled
in with our data. Please validate it against the rules below before I upload it to the system.

For each sheet, check every data row and report:
  • Rows that will definitely fail on import (row number, column, exact rule violated)
  • Rows that look suspicious or may cause problems (row number, concern)
  • A summary for each sheet: rows clean / rows with errors / rows with warnings

Row numbering starts at 2 (row 1 is the header).

════════════════════════════════════════════════════════════════
GENERAL RULES — apply to all sheets
════════════════════════════════════════════════════════════════

Dates must be in one of these formats:
  YYYY-MM-DD  |  DD/MM/YYYY  |  DDMMMYYYY (e.g. 31JAN2025)
  Any other format will be rejected.

Numbers must be valid. Comma thousands-separators are stripped
  automatically (1,234.56 is fine). Text such as "N/A" or a
  blank cell in a required numeric field will fail.

Required fields — a blank value causes a row-level error.

Trailing commas — flag any name or address field that ends
  with a comma. Trailing commas serve no purpose, look
  unprofessional, and interfere with searching and matching.

════════════════════════════════════════════════════════════════
UNITS SHEET
════════════════════════════════════════════════════════════════

Required: Unit Name, Unit Address

  • Unit Address must be a single line — no embedded line breaks,
    newline characters, or <br> tags.
  • If Category is provided, Type must also be provided on the
    same row.
  • If Core is provided, Area must also be provided on the same
    row.
  • Category values must logically belong to the specified Type.
  • Core values must logically belong to the specified Area.
  • If a UnitID column is present and has a value, the row is an
    update to an existing unit — flag any UnitID that looks like
    it may not correspond to a real record.
  • Schedule percentage columns must contain numeric values.

════════════════════════════════════════════════════════════════
CONTACTS SHEET
════════════════════════════════════════════════════════════════

Required: Person Last Name, Unit, Role

  • Unit and Role are mandatory on every row.
  • The Unit value must exactly match a Unit Name on the Units
    sheet. List any Contact rows where the Unit value does not
    match any unit.
  • Every unit that appears on the Units sheet must have at least
    one corresponding row on the Contacts sheet with a Role of
    either "Owner" or "Owner Occupier". List any units that have
    no such row.
  • Email (if provided) must be a valid email address.
  • Email is a unique person key. If the same email address
    appears on more than one row, then the Title, First Name,
    Person Last Name, and Phone values must be identical across
    all rows with that email. A mismatch means the rows would
    create conflicting records for the same person — flag these.
  • From Date and To Date (if provided) must be valid dates.
  • If Role is "Owner Occupier", the Address field should be left
    blank — the system knows they live in their unit and the unit
    address will be used. Flag any Owner Occupier row that has an
    address populated.
  • If Role is "Owner", an Address should be specified — owners
    live elsewhere and need a separate correspondence address.
    Flag any Owner row where Address is blank.
  • Address format (when provided): each line of the address
    should be separated by a newline character within the cell.
    Flag any address that uses commas as line separators or has
    a trailing comma at the end.
  • IntegrationId (if provided) must be unique per person — the
    same IntegrationId cannot appear against two different email
    addresses.

════════════════════════════════════════════════════════════════
SERVICE CHARGES SHEET (Accounts Receivable)
════════════════════════════════════════════════════════════════

Required: Unit, Type, Transaction Date, Budget Code, Amount,
          Schedule

  • The Unit value must exactly match a Unit Name on the Units
    sheet. List any rows where the Unit does not match.
  • Type must be exactly one of: Charge  Credit  Receipt
    (case-sensitive).
  • Transaction Date must be a valid date.
  • Amount for a Charge must be positive (> 0).
  • Amount for a Credit must be negative (< 0).
  • Amount for a Receipt should be negative (< 0). If most
    Receipt amounts are positive, flag as likely data-entry error.
  • On a Receipt row, if a Budget Code is provided it should be a
    bank account code — non-bank codes on receipts will fail.
  • Schedule is required on every row.
  • Rows sharing the same Unit + Transaction Date + Reference are
    grouped into one transaction — the Transaction Date must be
    identical across all rows in the group.

════════════════════════════════════════════════════════════════
PURCHASES SHEET (Accounts Payable)
════════════════════════════════════════════════════════════════

Required: Supplier, Type, Transaction Date, Supplier Reference,
          Budget Code, Amount, Schedule

  • The Supplier value must exactly match a Supplier name on the
    Suppliers sheet. List any rows where the Supplier does not
    match.
  • Type must be exactly one of: Purchase  PurchaseCredit  Payment
    (case-sensitive).
  • Transaction Date must be a valid date.
  • Supplier Reference is required, max 128 characters (prefer
    under 30).
  • Amount for a Purchase must be positive (> 0).
  • Amount for a PurchaseCredit must be negative (< 0).
  • Amount for a Payment must be negative (< 0). Positive payments
    are unusual — flag if the majority are positive.
  • Every Payment row must have a matching Purchase or
    PurchaseCredit row in the same sheet with the same
    Supplier + Supplier Reference. List any unmatched payments.
  • A Payment must not exceed the outstanding balance of its
    matched invoice.
  • If a budget code relates to a prepaid expense (insurance,
    rates, similar), both Service From and Service To are required.
  • Service From / Service To: if either is provided both must be
    provided; Service To must be on or after Service From. All
    rows grouped under the same invoice must have identical
    service dates.
  • Schedule is required on every row.

════════════════════════════════════════════════════════════════
BUDGET CODES SHEET
════════════════════════════════════════════════════════════════

Required: Name, Sort, Type

  • Sort must be a number.
  • Type must be a recognised type (income, expenditure, asset,
    liability, etc.).
  • Flag any Name that looks like it may duplicate an existing
    system account.

════════════════════════════════════════════════════════════════
SUPPLIERS SHEET
════════════════════════════════════════════════════════════════

Required: Supplier (name)

  • Flag any supplier name that looks like it may already exist
    (consider common abbreviations, Ltd vs Limited, etc.).
  • Email and Accounts Email (if provided) must be valid email
    addresses.

════════════════════════════════════════════════════════════════
TRIAL BALANCE SHEET
════════════════════════════════════════════════════════════════

Required: Budget Code, and either Debit or Credit (not both
          blank).

  • Total Debits across all rows must equal Total Credits.
  • Each Budget Code should appear only once.
  • Flag any row where both Debit and Credit are populated — each
    row should have a value in only one column.

CROSS-SHEET BALANCE CHECKS
  These checks require comparing figures across sheets. If the
  trial balance sheet and the transaction sheets are both present,
  please perform the following and report any discrepancy.

  First, identify the transfer date: this is the date the trial
  balance is stated as at (typically the last column heading or a
  note on the trial balance sheet). The transfer date is normally
  the first day of a financial year (e.g. 01-Jan-2024, 01-Apr-2024,
  01-Nov-2024). If it is not the first day of a month, or does not
  look like a typical year-start date, flag this as a probable issue
  — an unusual transfer date may indicate the trial balance and the
  transaction data are not aligned.

  For both reconciliations below, only include transactions dated
  on or before the transfer date. Transactions after the transfer
  date are year-to-date activity brought across separately and
  should not be included in the opening balance check.

  Debtors reconciliation:
    Net total of all Charges, Credits, and Receipts on the Service
    Charges sheet where Transaction Date <= transfer date
    (Charges positive, Credits and Receipts negative) must equal
    the Debtors balance on the Trial Balance sheet (i.e. the net
    debit balance on the Debtors budget code row).
    A mismatch means the transaction history does not fully explain
    the opening debtor position as at the transfer date.

  Creditors reconciliation:
    Net total of all Purchases, PurchaseCredits, and Payments on
    the Purchases sheet where Transaction Date <= transfer date
    (Purchases positive, Credits and Payments negative) must equal
    the Creditors balance on the Trial Balance sheet (i.e. the net
    credit balance on the Creditors budget code row).
    A mismatch means the purchase history does not fully explain
    the opening creditor position as at the transfer date.

---

Prompt 2 — Convert your existing data to template format

Use this prompt when you have data from a previous system, a spreadsheet, or an accountant’s export and need it mapped into the OMC import format. Attach whatever files you have — the AI will analyse them and produce correctly formatted CSV output for each applicable import type.

This works best with ChatGPT Plus (Code Interpreter) for complex reformatting, or Claude Pro for careful rule-following on cleaner source data.

I am attaching one or more files containing data from a previous system or existing spreadsheets.
Please analyse them and convert the data into CSV format suitable for import into the OMC
management system, following the target column layouts and rules below.

For each import type that has relevant data in my files, produce:
  1. A CSV block with the correct column headers and all mapped data rows
  2. A brief note on how you mapped each source column
  3. A list of anything you could not map and what information is needed to resolve it

If you are unsure which source column maps to which target column, make your best guess and
flag it clearly so I can check.

════════════════════════════════════════════════════════════════
TARGET FORMATS
════════════════════════════════════════════════════════════════

All output must follow these formatting rules:
  • Dates: YYYY-MM-DD only
  • Numbers: plain decimal, no currency symbols (€ £ $) and no
    thousands separators
  • Empty/unknown values: leave the cell blank — do not write
    N/A, -, or similar
  • Wrap any cell value that contains a comma in double quotes

──────────────────────────────────────────────────────────────
UNITS
──────────────────────────────────────────────────────────────
Columns:
  Unit Name, Unit Address, Type, Category, Unit Size, Bedrooms,
  Floor, Car Spaces, Area, Core, Unit Notes

  • Unit Name and Unit Address are required.
  • Unit Address must be a single line — remove any embedded
    line breaks.
  • Category requires Type; Core requires Area.

──────────────────────────────────────────────────────────────
CONTACTS
──────────────────────────────────────────────────────────────
Columns:
  Unit, Title, First Name, Person Last Name, Email, Phone,
  Address, Notes, Role, From Date, To Date, Entity Type,
  Contact Type, IntegrationId

  • Person Last Name, Unit, and Role are required on every row.
  • Unit must match a Unit Name from the units output exactly.
  • Every unit must have at least one row with Role of "Owner"
    or "Owner Occupier". Flag any units with no such row.
  • Role values: Owner, Owner Occupier, Resident, Director,
    Company Secretary, Keyholder (use the closest match).
  • Email must be a valid email address if provided.
  • If the same email address appears on multiple rows, the
    Title, First Name, Person Last Name, and Phone must be
    identical across all those rows.
  • If Role is "Owner Occupier", leave Address blank — the
    unit address will be used.
  • If Role is "Owner", populate Address with their
    correspondence address (they live elsewhere).
  • Address format (when provided): separate each line with a
    newline character within the cell. Do not use commas as line
    separators and do not add a trailing comma.
  • IntegrationId: if the source system has a unique person ID,
    put it here — it helps match records on re-import.

──────────────────────────────────────────────────────────────
SUPPLIERS
──────────────────────────────────────────────────────────────
Columns:
  Supplier, Code, Address, Contact Person, Phone, Email,
  Accounts Email, Bank Account Name, IBAN, Tax Registration,
  Notes

  • Supplier name is required and must be unique.

──────────────────────────────────────────────────────────────
SERVICE CHARGES — ACCOUNTS RECEIVABLE
──────────────────────────────────────────────────────────────
Columns:
  Unit, Type, Transaction Date, Note, Budget Code, Schedule,
  Amount, Reference

  • Unit must match a Unit Name exactly.
  • Type must be exactly: Charge, Credit, or Receipt.
  • Charges are positive amounts.
  • Credits and Receipts are negative amounts.
  • Budget Code must match an existing budget code name exactly.
  • Schedule must match an existing schedule name exactly.
  • Multiple line items for the same Unit + Date + Reference are
    valid — they group into one transaction.
  • The goal is to produce enough rows that the net balance per
    unit matches the debtor balance from the trial balance.

──────────────────────────────────────────────────────────────
PURCHASES — ACCOUNTS PAYABLE
──────────────────────────────────────────────────────────────
Columns:
  Supplier, Type, Transaction Date, Supplier Reference, Note,
  Budget Code, Schedule, Amount, Service From, Service To

  • Supplier must match a supplier name exactly.
  • Type must be exactly: Purchase, PurchaseCredit, or Payment.
  • Purchases are positive amounts.
  • PurchaseCredits and Payments are negative amounts.
  • Every Payment row must have a matching Purchase or
    PurchaseCredit row in the same output with the same
    Supplier + Supplier Reference.
  • Service From / Service To (optional): use for prepaid
    expenses such as insurance or rates. Both must be provided
    together; Service To must be on or after Service From.

──────────────────────────────────────────────────────────────
TRIAL BALANCE
──────────────────────────────────────────────────────────────
Columns:
  Budget Code, Debit, Credit

  • One row per budget code that has a non-zero balance.
  • Total Debits must equal Total Credits.
  • Budget Code must match existing budget code names exactly.
  • Include a row for each bank account showing its closing
    balance as a Debit.
  • The Debtors balance must equal the net total of all unit
    charges and receipts you have imported.
  • The Creditors balance must equal the net total of all
    outstanding supplier invoices you have imported.

════════════════════════════════════════════════════════════════

Now please analyse the attached files and produce the output.