Emerging technologies and capstone: designing controls for procure-to-pay

Accounting systems keep changing. Robotic process automation copies data between systems without human keying; artificial intelligence reads invoices, drafts reconciliations and answers questions about the ledger; digital reporting formats make financial statements machine-readable; electronic invoicing networks replace paper and PDF; and distributed ledgers promise shared records between organizations. Each technology changes where errors and fraud can happen and what controls are needed. This lesson surveys them from a controls point of view and then brings the course together in a capstone: designing the controls for Ridgeback's procure-to-pay process.

Robotic process automation

Robotic process automation (RPA) uses software robots, or bots, that mimic a person's actions in user interfaces: logging in, copying fields, pasting into another system, clicking buttons. Finance teams use bots for repetitive, rule-based work such as downloading bank statements, posting standard journal entries, matching simple items and preparing routine reports. Bots are fast and consistent, but they do exactly what they are told, including the wrong thing, thousands of times. A bot that posts the same journal entry twice or keys into the wrong field because a screen layout changed can create errors at scale.

Controls over RPA follow the IT general controls of lesson 9. Each bot should have its own user account with least-privilege access, never a shared human login, so its actions are traceable and it cannot exceed its role. Bot logic is a program and should go through change management, with testing whenever the underlying systems change. Bots need monitoring and exception handling: a human reviews items the bot could not process, and record counts and control totals confirm that the bot processed everything it should. Segregation of duties applies to bots too: a bot that can both create suppliers and release payments is as dangerous as a person who can.

Artificial intelligence in accounting

Machine learning and generative AI are now built into many finance tools. Extraction models read invoices and receipts. Anomaly detection flags unusual journal entries or payments. Forecasting models predict cash flow. Generative AI assistants draft memos, summarize contracts, explain variances and answer questions about data. These tools can save time and find patterns humans miss, but they introduce new risks: models can be wrong in ways that are hard to see, generative tools can produce confident but false answers (often called hallucinations), outputs can change when a vendor updates the model, and sensitive data may be sent outside the organization.

In March 2026 COSO published Achieving Effective Internal Control Over Generative AI, which applies the five components of the 2013 framework (lesson 8) to generative AI across its life cycle rather than creating a new framework. Its themes are practical: inventory the AI uses in the organization, classify them by what they do (for example, extracting data, transforming it, posting entries or supporting judgments), assess risks such as prompt manipulation, opaque reasoning, model drift and frequent changes, and apply proportionate controls. For an accounting team the minimum expectations include human review of AI outputs that affect the financial statements, documentation of which tool and version produced a result, restrictions on entering confidential data into tools that are not approved, testing of accuracy on known cases before and after changes, and clear accountability: the accountant who uses an AI output remains responsible for it.

Digital reporting and e-invoicing

eXtensible Business Reporting Language (XBRL) tags each number in a financial report with a standard label from a taxonomy, such as the IFRS taxonomy, so that software can read it without retyping. Inline XBRL embeds the tags in a human-readable document. Canadian securities regulators ran a voluntary XBRL filing program from 2007, but as of October 2026 Canada does not require operating companies to file financial statements in XBRL through SEDAR+, unlike the United States, where the SEC requires inline XBRL. Canadian companies that also list in the US file XBRL with the SEC. Check the CSA's current position before relying on this.

Electronic invoicing sends invoices as structured data rather than paper or PDF, so they can be validated and matched automatically. Since April 2022 suppliers to the Government of Canada have been required to submit invoices electronically through the federal procurement platform. There is no general business-to-business e-invoicing mandate in Canada as of October 2026, although the CRA has studied the idea; Canadian companies selling into countries with mandates, such as several in Europe, may still need to send compliant e-invoices, often through the Peppol network.

Blockchain, or distributed ledger technology, keeps a shared, append-only record that several parties can verify without a central keeper. In accounting it has been piloted for intercompany transactions, supply chain tracking and trade finance, and it underlies crypto assets that some organizations now hold or accept. For control purposes, a blockchain makes recorded data hard to alter but does nothing to make it correct when entered, so validation before recording matters, and the private keys that control assets or approvals need strong custody controls. Accounting for crypto assets themselves is a separate topic covered in later financial accounting courses.

Capstone: designing controls for Ridgeback's procure-to-pay process

Ridgeback's controller has asked you to design the controls for procure-to-pay as the company adds e-invoicing from its largest suppliers and an RPA bot to download supplier statements. Bring together the course's tools: document the process (lesson 2), identify risks at each step (lessons 6 and 8), select preventive and detective controls including ITGCs and application controls (lesson 9), address cybersecurity and fraud (lesson 11), and consider the new technologies. A risk and control matrix (RCM) lists each risk, the controls that address it, whether each is preventive or detective and manual or automated, the owner and the frequency. A simple coverage check confirms that every significant risk has at least one preventive and one detective control and that no single person owns conflicting controls.

# Ridgeback procure-to-pay: risk and control matrix coverage check (illustrative)
risks = {"R1": ("Fictitious supplier created", 5), "R2": ("Supplier bank details changed fraudulently", 5),
         "R3": ("Invoice paid twice", 4), "R4": ("Paid for goods not received or wrong price", 4),
         "R5": ("Payment file altered before bank", 4), "R6": ("Bot posts or downloads incorrectly", 3)}
controls = [
    ("C1", "Supplier creation needs documents and master-data role approval", "R1", "P", "auto", "master data lead"),
    ("C2", "Monthly supplier-employee address and bank match", "R1", "D", "auto", "internal audit"),
    ("C3", "Bank change call-back on known number, second approver", "R2", "P", "manual", "AP supervisor"),
    ("C4", "Alert old contacts; first payment after change reviewed", "R2", "D", "manual", "treasury"),
    ("C5", "ERP duplicate check on supplier, amount, normalized invoice number", "R3", "P", "auto", "AP supervisor"),
    ("C6", "Three-way match with 2% tolerance, consumed receipts", "R4", "P", "auto", "AP supervisor"),
    ("C7", "Monthly duplicate-payment and price-variance analytics", "R3", "D", "auto", "internal audit"),
    ("C8", "Encrypted bank file transfer and positive pay", "R5", "P", "auto", "treasury"),
    ("C9", "Daily bank reconciliation reviewed", "R5", "D", "manual", "controller"),
    ("C10", "Bot has own least-privilege account; changes tested", "R6", "P", "auto", "IT"),
]
for rid, (name, score) in risks.items():
    types = {c[3] for c in controls if c[2] == rid}
    gap = [t for t, label in (("P", "preventive"), ("D", "detective")) if t not in types]
    flag = "OK" if not gap else "GAP: no " + " and no ".join("preventive" if g == "P" else "detective" for g in gap)
    print(f"{rid} (score {score}) {name:45s} {flag}")
owners = {}
for cid, desc, rid, kind, mode, owner in controls:
    owners.setdefault(owner, set()).add(rid)
print("AP supervisor owns controls for:", sorted(owners["AP supervisor"]))

R1 (score 5) Fictitious supplier created                   OK
R2 (score 5) Supplier bank details changed fraudulently    OK
R3 (score 4) Invoice paid twice                            OK
R4 (score 4) Paid for goods not received or wrong price    GAP: no detective
R5 (score 4) Payment file altered before bank              OK
R6 (score 3) Bot posts or downloads incorrectly            GAP: no detective
AP supervisor owns controls for: ['R2', 'R3', 'R4']

The check shows two gaps. Risk R4 (paying for goods not received or at the wrong price) has a strong preventive control in the three-way match but no detective control on its own line; the monthly analytics (C7) cover price variances, so mapping C7 to R4 as well, or adding a review of match overrides, closes the gap. Risk R6, the bot, has preventive controls but nothing that detects a bad run; a daily reconciliation of the bot's record counts and totals to the source statements would close it. The owner listing shows the AP supervisor owns the bank change verification, duplicate check and three-way match. That is acceptable only if the supervisor cannot also enter invoices and release payment runs; otherwise the matrix needs to move one of those controls to treasury.

The capstone reflects the main message of the course. Reliable accounting information comes from well-designed systems: clean, well-structured data; documented processes; transaction cycles with preventive and detective controls; IT general controls that keep automated controls working; security and privacy practices that protect data and money; and governance that adapts as technology changes. The next courses build on this foundation: ACCT-341 applies data analytics to accounting data, and ACCT-331 and ACCT-431 apply controls knowledge in auditing.