Exports

Exports transfer documents, booking data, payment files, or status information to external systems.

Administrators should validate export logs, generated files, ERP responses, and retry behavior.

Export Categories

Export	Purpose	Typical risk
ERP invoice export	Transfers booking header and accounting rows to ERP.	Duplicate booking or rejected payload.
Payment file export	Creates payment files for banks or payment processing.	Incorrect payment data or duplicate payment file.
Status export	Sends payment, booking, or lifecycle status to an external system.	Stale or inconsistent status.
Document export	Sends files and metadata to another archive or portal.	Missing files or wrong metadata.
Report export	Generates CSV, Excel, PDF, or DOCX output.	Wrong filters or incomplete data.

ERP Exports

ERP exports usually require:

• valid client/accounting mapping,
• creditor or debtor address,
• bank connection if payment data is exported,
• currency,
• tax code,
• account and cost center,
• booking date and delivery date,
• accounting rows,
• document or attachment if required by the ERP.

Typical causes of ERP export errors:

Error area	What to check
Address	Missing ERP address number, inactive address, wrong creditor/debtor type.
Bank	Missing IBAN, missing internal bank, wrong payment type.
Currency	Currency not imported, missing daily rate, ERP expects own exchange-rate handling.
Tax	Tax code missing, wrong ERP field, invalid combination with account.
Accounting	Missing account, cost center, amount, accounting area, or balancing issue.
Permission	Export user or service user lacks write/export permission.

Payment Files

Payment files should be treated carefully because they can trigger real financial processing.

Before creating or sending payment files:

• verify selected invoices,
• verify bank account and IBAN,
• verify currency and amount,
• verify due date and payment terms,
• verify internal bank,
• check whether the file was already generated,
• confirm the target format and transmission process.

Retry Behavior

Export retry behavior must be explicit.

Safe retry depends on whether the external system has already accepted the export. If an ERP accepted a booking but centraQuest did not receive the response, a blind retry may create a duplicate booking.

For support cases, always capture:

• export job ID,
• object ID,
• external response,
• generated payload or file,
• external booking/reference number if available,
• current lifecycle state,
• whether the external system already contains the record.

Export Validation Checklist

After an export, verify:

• the source object changed to the expected status,
• the export response is stored or logged,
• generated files are available,
• external references are written back,
• payment or booking status is visible,
• failed records remain actionable,
• retries are documented.