Keep invoice follow-up connected to your existing records.

Start with the system that owns the balance

Following up an invoice requires more than a customer’s email address. The person preparing a reminder needs the issued reference, due date, currency, remaining balance and any reason to pause. Those details must come from an agreed accounting source. A contact exported after a sales enquiry does not establish whether an invoice exists or whether it has been paid.

Procora’s own subscription billing concerns what a business pays for Procora. It is separate from the money that business’s customers owe it. Connecting one does not connect the other. The proposed service would organise follow-up around existing records; it would not replace bookkeeping, create invoices or change the accounting ledger.

What the existing connections actually do

The existing e-conomic connector exports enquiry information to customer records. It does not provide a verified invoice, credit or payment feed for this service. Dinero and Billy appear in the connection catalogue as contact-export routes through automation. That catalogue placement does not establish receivables synchronisation. These are useful distinctions when assessing an existing Procora setup.

An invoice connection to Xero or QuickBooks has not been verified for Procora. Their names identify systems a business may ask us to assess, not ready-to-use integrations. The capability table separates current contact-related work from invoice access requiring implementation. Any future connection needs its own access review, field mapping and tests before it can support reminders.

Agree the information before agreeing the automation

A proposed import would need a stable invoice identifier, customer identifier, issue and due dates, currency, gross amount, applied credits, allocated payments and remaining balance. Contact authority, invoice state, disputes and the last source update also matter. A named owner should confirm how each field is obtained and what a blank or missing value means.

Begin with read-only access where practical. Permitted changes must be listed separately; permission to read invoices does not authorise changing terms, bank details or balances. Only include records within the agreed business, currency and date scope. Match updates using source identifiers, rather than treating a repeated export as a new invoice or relying on a customer name alone.

A snapshot and a live connection need different rules

A manually supplied spreadsheet describes a position at a particular time. It cannot tell you about a payment received afterwards. An agreed scheduled connection would refresh records at stated intervals; even then, delays and failed updates remain possible. Procora does not currently offer a verified invoice import or live payment synchronisation for this planned service. Both approaches need implementation and validation.

In a proposed workflow, show the source date beside the invoice and the date it was last checked. Agree when information is too old for a reminder. If that threshold is exceeded, the next action should become a source check for the owner, rather than sending a message based on an old balance. Refreshing a record should never silently remove an unresolved query.

Example: a credit and a payment are different events

The fictional EX-103 invoice starts at £2,000. An applied £200 credit reduces what is owed; an allocated £1,800 payment settles the rest. Its remaining balance is £0. A correct source mapping keeps those events separate: £1,800 was paid, while £200 was credited. Reporting £2,000 as collected cash would misstate the result.

EX-101 still has £900 remaining after a £300 part payment. A customer reply saying “paid” is useful context, but it is not a payment record. The proposed workflow would pause ordinary reminders and request verification. The public example only closes that balance after a simulated payment allocation; it never checks a bank or processes real money.

What happens if updates fail or access is removed?

A failed update should be visible to the person responsible for the source. Keep the last successful timestamp and explain which invoices may be affected. Do not replace a known balance with zero because a request failed or returned incomplete data. A disconnection should stop reliance on that feed and hold dependent reminders until an authorised person confirms a safe next step.

Bring the name of your accounting system, the type of invoice records you need and your current reminder process to a scope discussion. Do not send credentials or customer files through the public enquiry. We can identify the access, development and checks a possible pilot would require before making any commitment about a connection or activation date.

Explore the example