Redesign procure-to-pay and order-to-cash around D365 documents — retiring the staging-table operating model that Voucher Build and the Billing Interface established, while preserving the integration semantics and controls that actually mattered.
Procure-to-pay and order-to-cash look like the most conventional part of a PeopleSoft migration. Vouchers become vendor invoices. Billing invoices become customer invoices. Purchase orders become purchase orders. The concept mapping rates most of these object-level translations at high confidence, and several as direct.
PeopleSoft's inbound document architecture has a consistent shape. A feeder — an expense system, a procurement card feed, a subsidiary, a legacy application — writes rows into staging structures. A build process reads those rows, applies defaults and validation, resolves the reference data, and creates the document.
Work the redesign per feeder, not per staging table. For each feeder that currently creates vouchers, establish:
The billing side carries the same instruction with a different emphasis. The concept note asks that billing interface and AR accounting be grouped by invoice class, not just by table lineage.
Both party masters are rated direct and high confidence at object level, and both carry the same attached redesign.
Document identity on the purchasing side transfers cleanly. A purchase order is a purchase order; a receipt becomes a product receipt. What changes is the accounting weight of the receipt.
The customisation register treats AWE and approval logic as a medium-effort item with a pointed instruction: rebuild high-value approvals only; simplify over-custom routing. It adds that approval behaviour can also be embedded in PeopleCode, which means an AWE configuration extract is not a complete approval inventory.
The register rates Excel-to-CI templates at medium effort, with a target of the Excel add-in, data management or Power Apps, and an instruction to retain only controlled-entry scenarios not covered by standard import. Its closing note is worth taking seriously: spreadsheet dependence often signals weak upstream integration.
Trade documents are the largest open-item population at cutover, and the playbook's wave model separates them deliberately: open sales and purchase orders in one wave, inventory positions in another, and open receivables and payables in a later one.
Trade on a PeopleSoft programme is a set of direct object mappings surrounded by machinery that does not transfer.