Procure to Pay workflow controls

See workflow control test. This should be tested in line with a standard workflow process.

Note that this control covers the workflow, not the accuracy of the approvers for each level of approval.

• Should raising and approving of purchase orders always be segregated, or can approvers also raise purchase orders up to their approval threshold without any need for further approval?

• Is the manual of authority up to date in the system, and has taken account of any staff movements to different roles in the organization?

• Will purchase order raisers be able to select the approver, or will this be predefined in the manual of authority?

• Designate sufficient approvers to cover any work absences

• Will approval for higher value purchase orders be required from each approver in the chain, or will purchase orders be sent directly from the raiser to the individual with an approval limit sufficiently high to deal with the purchase order?

Matrix of authorities contained in system:

Purchasing > All tab > Other transaction activity > Approve transactions.

This test, in conjunction with the test of Purchase order approval workflow, should focus on the correctness of the people in the workflow, rather than the configuration of the workflow.

The test is conducted by comparing the list of approvers in the system to the approved .

• What de minimis level should you set?

• Consider how you will execute reporting over purchase orders that have not been approved (how frequently this report will be run, and who will review it)

Custom List Views filtered by appropriate State

Purchasing > All tab > Other transaction activity > View transactions > Manage views > Create new view > Step 3: Select filters > State equals (appropriate values might include: Submitted, Partially Approved, Declined, Draft, Pending)

Purchase order approval configuration and limits within system.

View custom report configurations in:

Reports > Custom Reports > Add

Evidence should be retained that a reviewer has checked the report to identify any purchase orders they consider to have been raised without approval appropriately, such as a marked up copy of the report, or a digitally signed version indicating what has been reviewed.

See review control test.

Care should be taken to understand how inappropriate transactions are identified, and followed up.

This control is a review of all purchase orders, to ensure that they’re valid. This is likely to be a large list, so you will want to define how you are going to do this test each time without it being overly burdensome. Focusing on risky purchase orders, people, values or entities will help, as will a sampling methodology. The main thing is that it needs to be consistent.

Some of the checks that could be done include:

• Checking who is raising purchase orders - are they as expected?

• Selecting a sample of purchase orders to ensure they’re accurate and not fraudulent;

• Looking at the values of purchase orders - are people trying to get purchase orders through without approval by making them just below the approval limit?

Purchase order reporting of non-approved purchase orders is the control that involves reviewing just purchase orders that have no approval (if this is something that has been allowed).

• How will you identify what constitutes an error, misstatement or fraud?

• How will you ensure that this review is done consistently each time it is performed?

• You might wish to split this out by entity or amount. How will you ensure that everyone does this consistently? Will there be central organization / monitoring of the reviews?

• How will you ensure that the person signing off is not responsible for raising purchase orders? Consider either a secondary check or ensuring the reviewer does not have access to raise purchase orders / is not someone from the Purchasing department.

Purchasing > All > Reports

Several standard reports are available to show a variety of information. Custom reports can be created to pull additional information if required.

List of purchase orders with annotations by the reviewer. Follow up queries should be evidenced. Ensure it is clear what the conclusions were and how they were reached

See review control test.

Take care to understand how inappropriate purchase orders are identified, and followed up.

The control looks for purchase orders that haven't been raised against a supplier contract or purchase requisition. You would use this control if you're trying to enforce the use of purchase requisitions or supplier contracts for all purchase orders, otherwise the listing would be long.

• How will you perform follow-up on these purchase orders?

• How will you ensure that the review is efficient, for example that you're not following up on the same purchase orders each month?

Create specific transaction definitions for purchase orders that do not require conversion from other purchasing transactions, and create a Custom List View for these specific transaction definitions.

• Transaction definitions - Workflow

• Add a custom view

Annotated listing of unlinked purchase orders, with verification that the purchase order is appropriate (with reasoning and backup retained)

See review test.

The test should focus on ensuring the inappropriate purchase orders are correctly identified and followed up.

See workflow control test. This should be tested in line with a standard workflow process.

Note that this control covers the workflow, not the accuracy of the approvers for each level of approval.

• Should raising and approving of purchase orders always be segregated, or can approvers also raise purchase orders up to their approval threshold without any need for further approval?

• Is the manual of authority up to date in the system, and has taken account of any staff movements to different roles in the organization?

• Will purchase order raisers be able to select the approver, or will this be predefined in the manual of authority?

• Designate sufficient approvers to cover any work absences

• Will approval for higher value purchase orders be required from each approver in the chain, or will purchase orders be sent directly from the raiser to the individual with an approval limit sufficiently high to deal with the purchase order?

Matrix of authorities contained in system:

Purchasing > All tab > Other transaction activity > Approve transactions.

This test, in conjunction with the test of Purchase order approval workflow, should focus on the correctness of the people in the workflow, rather than the configuration of the workflow.

The test is conducted by comparing the list of approvers in the system to the approved .

• What de minimis level should you set?

• Consider how you will execute reporting over purchase orders that have not been approved (how frequently this report will be run, and who will review it)

Custom List Views filtered by appropriate State

Purchasing > All tab > Other transaction activity > View transactions > Manage views > Create new view > Step 3: Select filters > State equals (appropriate values might include: Submitted, Partially Approved, Declined, Draft, Pending)

Purchase order approval configuration and limits within system.

View custom report configurations in:

Reports > Custom Reports > Add

Evidence should be retained that a reviewer has checked the report to identify any purchase orders they consider to have been raised without approval appropriately, such as a marked up copy of the report, or a digitally signed version indicating what has been reviewed.

See review control test.

Care should be taken to understand how inappropriate transactions are identified, and followed up.

This control is a review of all purchase orders, to ensure that they’re valid. This is likely to be a large list, so you will want to define how you are going to do this test each time without it being overly burdensome. Focusing on risky purchase orders, people, values or entities will help, as will a sampling methodology. The main thing is that it needs to be consistent.

Some of the checks that could be done include:

• Checking who is raising purchase orders - are they as expected?

• Selecting a sample of purchase orders to ensure they’re accurate and not fraudulent;

• Looking at the values of purchase orders - are people trying to get purchase orders through without approval by making them just below the approval limit?

Purchase order reporting of non-approved purchase orders is the control that involves reviewing just purchase orders that have no approval (if this is something that has been allowed).

• How will you identify what constitutes an error, misstatement or fraud?

• How will you ensure that this review is done consistently each time it is performed?

• You might wish to split this out by entity or amount. How will you ensure that everyone does this consistently? Will there be central organization / monitoring of the reviews?

• How will you ensure that the person signing off is not responsible for raising purchase orders? Consider either a secondary check or ensuring the reviewer does not have access to raise purchase orders / is not someone from the Purchasing department.

Purchasing > All > Reports

Several standard reports are available to show a variety of information. Custom reports can be created to pull additional information if required.

List of purchase orders with annotations by the reviewer. Follow up queries should be evidenced. Ensure it is clear what the conclusions were and how they were reached

See review control test.

Take care to understand how inappropriate purchase orders are identified, and followed up.

The control looks for purchase orders that haven't been raised against a supplier contract or purchase requisition. You would use this control if you're trying to enforce the use of purchase requisitions or supplier contracts for all purchase orders, otherwise the listing would be long.

• How will you perform follow-up on these purchase orders?

• How will you ensure that the review is efficient, for example that you're not following up on the same purchase orders each month?

Create specific transaction definitions for purchase orders that do not require conversion from other purchasing transactions, and create a Custom List View for these specific transaction definitions.

• Transaction definitions - Workflow

• Add a custom view

Annotated listing of unlinked purchase orders, with verification that the purchase order is appropriate (with reasoning and backup retained)

See review test.

The test should focus on ensuring the inappropriate purchase orders are correctly identified and followed up.

Limiting the combinations that can be posted reduces the possibility of postings being made to the wrong of entities, profit, and cost centers (either deliberately or in error).

• What are the combinations of entity, profit center and cost center that need to be defined?

• Are there any circumstances in which these definitions might need to be changed?

This can be controlled by a variety of actions. Access to certain transaction definitions can be limited to certain users (Purchasing > Setup > Transactions definitions, select Edit next to the applicable transaction definition, and edit the access on the Security tab).

A second level would be to create Smart Rules to validate permissible dimension combinations.

• Security configuration

• Smart rules

System posting configuration permissions.

See configuration test.

The test should focus on the elements of the validation that ensure the integrity of financial reporting.

This is similar to the unapproved purchase order review in Aged unapproved purchase order review, but this lists unapproved purchase orders in specific supplier contracts.

You might not need this control if you don’t use supplier contracts or if unapproved purchase orders are not a big problem.

• How will you ensure that this review is done consistently each time it is performed?

• You might want to split this out by entity or amount. How will you ensure that everyone does this consistently? Will there be central organization / monitoring of the reviews?

Create a custom report:

Customization Services or Platform Services > All tab > Custom Reports

Annotated unapproved purchase order listing, evidencing follow-up as needed / rationale for the purchase order being unapproved.

See review control test.

The test should focus on ensuring the inappropriate purchase orders are correctly identified and followed up.

This is similar to the unapproved purchase order review in Aged unapproved purchase order review, but this lists unapproved purchase orders in specific supplier contracts.

You might not need this control if you don’t use supplier contracts or if unapproved purchase orders are not a big problem.

• How will you ensure that this review is done consistently each time it is performed?

• You might want to split this out by entity or amount. How will you ensure that everyone does this consistently? Will there be central organization / monitoring of the reviews?

Create a custom report:

Customization Services or Platform Services > All tab > Custom Reports

Annotated unapproved purchase order listing, evidencing follow-up as needed / rationale for the purchase order being unapproved.

See review control test.

The test should focus on ensuring the inappropriate purchase orders are correctly identified and followed up.

If purchase orders are unapproved, there might be a delay in sending them out and getting the goods. This might be due to absence by the approver, or something going wrong in the approval workflow. It is useful to check the “unapproved purchase order” list view to ensure that the purchase order process is going smoothly.

Whether this is a control that's done formally (with well-documented evidence) or informally will depend on whether this is likely to be a big problem or not.

• How will you ensure that this review is done consistently each time it is performed?

• You might wish to split this out by entity or amount. How will you ensure that everyone does this consistently? Will there be central organization / monitoring of the reviews?

Custom list views filtered by appropriate state

Purchasing > All tab > Other transaction activity > View transactions> Manage views > Create new view > Step 3: Select filters > State equals (appropriate values might include: Submitted, Partially Approved, Declined, Draft, Pending)

Annotated unapproved purchase order listing, evidencing follow-up as needed / rationale for the purchase order being unapproved.

See review control test.

Take care to ensure that the control meets the objective.

This control prevents the organization for recording the receipt for more of a good or service than has been properly approved through the purchase order approval process, and prevents the organization from over-paying invoices.

• Capacity to allocate multiple receipts against a single purchase order.

• Capacity to mark purchase order as complete when full value has not been reached

Ensure that the Transaction Definition for the Goods/Service Receipt has two settings configured:

1. Transaction conversion to include Purchase Order (and other relevant transaction definitions)

2. Create Policy (Security Configuration tab > Document permissions) should be set to Convert only.

For transacting, users will go to Purchasing > All > Transactions > Purchase Order > Convert (on relevant purchase order)

After the purchase order is converted fully the order will be marked as complete and no further deliveries can be made.

Configuration settings in:

Purchasing > Purchase Order > Convert (on relevant purchase order)

See configured / coded control test.

This test should focus on ensuring the blocking functionality works as expected.

This control ensures that the organization recognizes a liability for any goods or services received in case there's a time lag between goods or services being delivered and an invoice being received.

When a PO purchase invoice is received, the accrual is removed and a liability to the supplier is recognized until the invoice is paid.

None.

Fulfillment (Shipping) transaction definitions can be configured to post directly to the General Ledger to book to an accrual or encumbrance account, and the subsequent transactions (PO purchase invoice) can include the reversal of the accrual.

For the fulfillment (shipping) transaction definition:

1. Go to Accounting > Transaction posting > General Ledger.

2. Complete the Posting Configuration tab.

For the PO purchase invoice transaction definition:

1. Go to Accounting > Transaction posting > Accounts Payable, and enable Additional posting.

2. Complete both the Transaction posting AP account mapping and the Additional GL posting account mapping sections on the Posting Configuration tab.

Go to Purchasing > Setup > Configuration > Documents configuration tab and assign the correct Journal code for the accrual posting for both transaction definitions.

• Transaction definitions - Accounting

• Purchasing documents configuration

Configuration settings in:

Purchasing > Setup tab > More, demonstrating automatic accruals enabled under Transaction definitions.

See configured / coded control test.

This test should focus on ensuring the accrual is automatic, and the calculation is accurate.

Aged items, where a goods receipt has been made but no subsequent invoice has been matched to that goods receipt are often an indicator of accounting errors, such as the invoice being lost, or matched to an incorrect purchase order.

How old does an unmatched item have to be before it requires investigation.

Create a financial report with dimension analysis to review accrual balances by supplier.

Dimension analysis in financial reports

Annotated report.

See review control test.

This test should focus on how problematic receipts are identified and followed up.

Self-receipting might or might not be a risk depending on the day-to-day business approach. What will be important is ensuring that the report is reviewable; otherwise there could be many items that might promote a cursory review.

Is self-receipting a normal occurrence? If so, this report will produce a large number of items for review. It will be important to identify which items that are genuinely risky, for example, large items, or certain types of goods or services. This threshold should be applied consistently.

Create a custom report:

Customization Services or Platform Services > All tab > Custom Reports

Custom Report Writer

Reviewed audit trail, with evidence of follow-up where the threshold (if applicable) has been exceeded.

See review control test.

The test should focus on how inappropriate self-receipts were identified and followed up.

Review of blocked invoices is one of several checks that should be made around the period end to ensure that all relevant liabilities have been completely and accurately recorded, and in the correct period, and from an operational perspective, the reasons for invoice differences to purchase orders are understood and resolved on a timely basis to ensure that invoices can be processed.

Often a PO purchase invoice will be held for a valid reason, such as a mismatch with the purchase order, but the goods or services have been received and therefore the organization should accrue for the costs, even if the invoice has been held.

• Who will generate a report to review blocked invoices?

• How frequently will the report be run?

• Who will review the reporting and what actions will they take?

Custom Report or Custom List Views filtered by appropriate state

State equals (appropriate values can include: Submitted, Partially Approved, Declined, Draft, Pending)

• Custom Report Writer

• Add a custom view

Report available through:

Platform Services> All > Custom Reports

Evidence of control performance should be an annotated report, with comments and followup documentation retained.

See review control test.

This test should ensure that appropriate evidence of review and action is recorded.

Not all invoices will originate from company initiated purchase orders. Many will come directly from service providers. Where these are regular purchases or involve data from other purchasing systems, it is important to be able to reconcile between Sage Intacct and the third-party system to ensure that data has been completely and accurately recorded

• What are the characteristics of invoices generated by third party applications?

• How will these be identified in Sage Intacct data (for example, unique GL account, document type, or other characteristic

• What reports are required from the 3rd party application to enable a reconciliation to Sage Intacct data?

Configurations will vary per integration.

Create a custom report:

Customization Services or Platform Services > All > Custom Reports

Custom Report Writer

Sage Intacct Developer portal (REST API)

Report available through:

Platform Services > All > Custom Reports

Evidence of control performance should be an annotated report, with comments and follow-up documentation retained.

See reconciliation control test.

Reconciling transactions between systems is a good way of checking the integrity of the interface, though the effort spent on this depends on the likelihood of interface problems - it is not worth spending a lot of time reconciling if the interface is simple and/or robust.

The key thing is to demonstrate the reconciliation - where did you get the information from, how did you match them up, and what did you do with the differences?

• At what level will you be reconciling? # lines, control total, or by line item?

• How often will you be reconciling (daily, weekly, monthly) and how will you ensure that nothing is missed?

• What are the thresholds for reconciling items? What will you do if there's for example, a penny difference?

Configurations will vary per integration.

Create a custom report:

Customization Services or Platform Services > All tab > Custom Reports

• Custom Report Writer

• Sage Intacct Developer portal (REST API)

Reconciliation documentation, including reconciling items and follow-up.

See reconciliation control test.

This control is intended to prevent payments being made to suppliers that the organization has not properly accepted, which might result in financial loss to the organization or fraudulent payments being made.

Will there be any circumstances where invoices might need to be accepted for emergency payments (where a supplier does not exist), or one-off payments?

To deactivate suppliers, which removes it from being listed:

1. Go to Accounts Payable > All > Suppliers.
2. Find the supplier you want to deactivate.
3. Select Edit at the end of the row.
4. On the Supplier tab, change the Status for the supplier to Inactive.
5. Select Save.

1. Go to Accounts Payable > All > Suppliers.
2. Find the supplier you want to deactivate.
3. Select Edit next to the appropriate supplier.
4. On the Supplier tab, change the Status for the supplier to Inactive.
5. Select Save.

To temporarily place a supplier on hold:

1. Go to Accounts Payable > Setup > Configuration .

2. Scroll to the Thresholds section and select the appropriate setting for If supplier is on hold, such as Warn or Do not allow transactions to be created.

3. Update individual supplier records, as appropriate:

   1. Go to Accounts Payable > All > Suppliers.
   2. Find the supplier you want to place on hoild.
   3. Select Edit at the end of the row.
   4. Select the Additional Information tab , scroll to the Billing details section, and select Hold.
   5. Select Save.
   1. Go to Accounts Payable > All > Suppliers.
   2. Select Edit next to the supplier to put on hold.
   3. Select the Additional Information tab , scroll to the Billing details section, and select Hold.
   4. Select Save.

• Inactivate a supplier

• Supplier credit limits

System configuration for accounts payable suppliers and invoice acceptance.

See configuration test.

The test should focus on ensuring the functionality of blocking inactive or non-existent suppliers.

Typically invoices should only be received for goods that have been properly ordered through a purchase order. Occasionally, purchases need to be made at short notice where there's no time to create a purchase order, or are for very low value purchases. In these cases, the workflow approval of the invoice compensates for this lack of approval at a purchase order stage, and ensures that the purchase is for a valid purpose.

• Who should be permitted to approve invoices? They should not be the person making the purchase.

• Will there be any broader review of invoices with purchase order approved to ensure purchases are not being made to avoid the purchase order approval process, or for some other reason?

Create specific transaction definitions for PO purchase invoices that do not require conversion from other purchasing transactions, and create a custom list view for these specific transaction definitions.

• Purchasing transaction definitions - Workflow

• Add a custom view

Approval workflow audit trail indicating approvers of invoice.

Approvers configured in:

Purchasing > Setup > Configuration > Workflow

See workflow control test.

This control is intended where invoices do not go through a 2-way (purchase order to invoice) or 3-way (purchase order - goods receipt - invoice receipt) process. This might be because the purchase to pay process is informal and invoices are entered directly into Sage Intacct, or because the nature of the expenditure is that a purchase order is not practical (for example, office rental, utility bills)

Review of parked invoices (invoices entered directly but not posted) is one of several checks that should be made around the period end to ensure that all relevant liabilities have been completely and accurately recorded, and in the correct period.

• Who will generate a report to review parked invoices?

• How frequently will the report be run?

• Who will review the reporting and what actions will they take?

Create a custom report:

• Customization Services or Platform Services > All tab > Custom Reports Custom List Views filtered by appropriate State

• Purchasing > All tab > Other transaction activity > View transactions > Manage views > Create new view > Step 3: Select filters > State

State values can include: Submitted, Partially Approved, Declined, Draft, Pending

• Custom report writer

• Add a custom view

Report available through:

Customization Services or Platform Services > All tab > Custom Reports

Evidence of control performance should be an annotated report, with comments and follow-up documentation retained.

See review control test.

The test should focus on the activities to prevent inappropriate postings, not simply to see invoices that are posted. This might require specific positive evidence of review.

This control is intended where there are multiple purchasing systems in place, e.g purchasing through Sage Intacct and another purchase application - for example an industry-specific application. In this situation there can be a risk of duplicate payments because orders are recorded on 2 systems.

• How will you define what a duplicate is? What elements of the invoice should be compared?

• If you are using multiple invoice entry points (for example, multiple interfaces), is there anything that needs to be done to ensure that the duplications will be identified? For example, each system adds a code to the invoice number that means that the invoices look different when compared; or the exchange rate used is slightly different so that the amounts don't match; or the risk that a supplier name is different between two systems.

• What's the timing of this control?

Create a custom report:

Customization Services or Platform Services > All tab > Custom Reports

Custom report writer

Annotated report, with comments and followup documentation retained, of items defined as being potentially duplicative.

See configuration test.

The test should focus on prevention of duplicate invoices, according to the preset criteria for duplication (which fields are checked)?

Unlike most other controls, this control is not specifically designed. Invoice analysis could be used to identify fraud, or unusual activity, or to support other controls. Generally speaking, this control in and of itself would not likely directly address a financial reporting risk.

It's not recommended to just implement a generic "analyze invoices" control with no specific purpose, as it will be hard to demonstrate that this is actually addressing a financial statement risk.

Note that this functionality may be used to mitigate the impact of a control failure elsewhere in the purchase to pay process - to demonstrate that a weakness in control has not had a significant impact. This would be achieved by running reports of invoices in the area impacted by the control weakness. For example, an auditor may have identified a weakness in controls relating to a particular supplier, running reports on all invoices from that supplier could determine if the audit issue was a one-off, or constrain the total amount of the error.

Note that there are several potential controls that could be designed off the back of this report, which can achieve different purposes.

Whatever control is designed, it is important that it is done consistently, with the same criteria applied each time. This prevents the risk that the control becomes overreliant on the ability and experience of the person doing the review.

Purchasing > All > Reports

Several standard reports are available to show a variety of information. Custom reports can be created to pull additional information if required.

Purchasing reports overview

Annotated report, with comments and follow-up documentation retained.

See review control test.

The test should be carefully designed to ensure that the control objective is met - not a general check that some kind of review happened.

Blocking the ability to change the payment terms will ensure people can't try to force a payment through quickly for fraudulent purposes.

• Are there any reasons that you might want to change the payment terms? If so, what will you do if this is needed, to ensure that you don't pay suppliers late and incur penalties?

• If not used, Review of changes to payment terms should be considered.

Go to Company > Admin > Roles or Users > Subscriptions > Permissions and review existing permissions.

Permissions

Go to roles or permissions set up page (Company > Admin > Roles or Users > Subscriptions > Permissions) and review existing permissions to ensure access is restricted to specific individuals.

See configuration/coded control test.

The functionality to be tested is the blocking of changing payment terms (if enabled).

Review of payment terms changes is a way to detect potential fraud, but this control needs to be done in the context of policies and expectations being communicated clearly. Ideally, you would set expectations through a policy and then review the report of changes to ensure there's no deviation from the policy.

• This should be used if Payment terms change configuration is not used (that is, if changes to payment terms are not blocked).

• Review needs to be done consistently, and on a frequency commensurate with the risk. That is, if changing payment terms is considered a high risk, it should be done more frequently.

• How will you ensure you differentiate between legitimate changes and fraudulent changes?

• What level of payment term changes are there likely to be?

• How will you communicate the expectations (for example. that staff do not change payment terms except in "exceptional circumstances")?

Run the ‘Audit History by Object Data Area Report’ filtered by appropriate object data areas.

Use an Audit History report

See review control test.

The test should focus on how the inappropriate changes were identified and followed up.

Three-way matches are intended to make sure that the goods or services received match up to what was ordered, and that the supplier is invoicing the correct amount for this. If this isn’t the case, the system won’t allow the invoice to be paid until the difference is resolved.

To avoid very small differences preventing invoice payment, set an ‘overrage’ threshold (normally a % or absolute value) that you’re happy to tolerate.

The control therefore stops suppliers being paid before they have supplied what was ordered, and highlights any problems with invoicing before the invoice is paid.

• Tolerance threshold set at level sufficient to allow permissible overages.

• Whether permitted mismatches should be monitored to identify any consistent differences.

• Ability to specify shipping costs separately to the cost of purchase in the matching process so as not to trigger mismatches.

Ensure that the transaction definitions have the following two settings configured:

• Transaction conversion to include only relevant transaction definitions

• Create Policy (Security Configuration tab > Document permissions) should be set to Convert only

For transacting, users will go to Purchasing > All > Transactions > Purchase Order > Convert (on relevant purchase order).

The system does not allow a receipt in excess of the purchase order quantity. Any increase in quantity received would require a new purchase order

Purchasing transaction definitions

Three-way matching configuration set in Purchasing > Purchase Order > Convert (on relevant purchase order).

The system does not allow a receipt in excess of the purchase order quantity. Any increase in quantity received would require a new purchase order.

See configuration control test.

The three-way match functionality should be tested, along with any threshold for acceptance and blocking of invoices above the threshold.

Review of blocked invoices is one of several checks that should be made around the period end to ensure that all relevant liabilities have been completely and accurately recorded, and in the correct period, and from an operational perspective, the reasons for invoice differences to purchase orders are understood and resolved on a timely basis to ensure that invoices can be processed.

Often a PO purchase invoice will be held for a valid reason, such as a mismatch with the purchase order, but the goods or services have been received and therefore the organization should accrue for the costs, even if the invoice has been held.

• Who will generate a report to review blocked invoices?

• How frequently will the report be run?

• Who will review the reporting and what actions will they take?

Custom Report or Custom List Views filtered by appropriate state

State equals (appropriate values can include: Submitted, Partially Approved, Declined, Draft, Pending)

• Custom Report Writer

• Add a custom view

Report available through:

Platform Services> All > Custom Reports

Evidence of control performance should be an annotated report, with comments and followup documentation retained.

See review control test.

This test should ensure that appropriate evidence of review and action is recorded.

Not all invoices will originate from company initiated purchase orders. Many will come directly from service providers. Where these are regular purchases or involve data from other purchasing systems, it is important to be able to reconcile between Sage Intacct and the third-party system to ensure that data has been completely and accurately recorded

• What are the characteristics of invoices generated by third party applications?

• How will these be identified in Sage Intacct data (for example, unique GL account, document type, or other characteristic

• What reports are required from the 3rd party application to enable a reconciliation to Sage Intacct data?

Configurations will vary per integration.

Create a custom report:

Customization Services or Platform Services > All > Custom Reports

Custom Report Writer

Sage Intacct Developer portal (REST API)

Report available through:

Platform Services > All > Custom Reports

Evidence of control performance should be an annotated report, with comments and follow-up documentation retained.

See reconciliation control test.

Reconciling transactions between systems is a good way of checking the integrity of the interface, though the effort spent on this depends on the likelihood of interface problems - it is not worth spending a lot of time reconciling if the interface is simple and/or robust.

The key thing is to demonstrate the reconciliation - where did you get the information from, how did you match them up, and what did you do with the differences?

• At what level will you be reconciling? # lines, control total, or by line item?

• How often will you be reconciling (daily, weekly, monthly) and how will you ensure that nothing is missed?

• What are the thresholds for reconciling items? What will you do if there's for example, a penny difference?

Configurations will vary per integration.

Create a custom report:

Customization Services or Platform Services > All tab > Custom Reports

• Custom Report Writer

• Sage Intacct Developer portal (REST API)

Reconciliation documentation, including reconciling items and follow-up.

See reconciliation control test.

Typically invoices should only be received for goods that have been properly ordered through a purchase order. Occasionally, purchases need to be made at short notice where there's no time to create a purchase order, or are for very low value purchases. In these cases, the workflow approval of the invoice compensates for this lack of approval at a purchase order stage, and ensures that the purchase is for a valid purpose.

• Who should be permitted to approve invoices? They should not be the person making the purchase.

• Will there be any broader review of invoices with purchase order approved to ensure purchases are not being made to avoid the purchase order approval process, or for some other reason?

Create specific transaction definitions for PO purchase invoices that do not require conversion from other purchasing transactions, and create a custom list view for these specific transaction definitions.

• Purchasing transaction definitions - Workflow

• Add a custom view

Approval workflow audit trail indicating approvers of invoice.

Approvers configured in:

Purchasing > Setup > Configuration > Workflow

See workflow control test.

This control is intended where invoices do not go through a 2-way (purchase order to invoice) or 3-way (purchase order - goods receipt - invoice receipt) process. This might be because the purchase to pay process is informal and invoices are entered directly into Sage Intacct, or because the nature of the expenditure is that a purchase order is not practical (for example, office rental, utility bills)

Review of parked invoices (invoices entered directly but not posted) is one of several checks that should be made around the period end to ensure that all relevant liabilities have been completely and accurately recorded, and in the correct period.

• Who will generate a report to review parked invoices?

• How frequently will the report be run?

• Who will review the reporting and what actions will they take?

Create a custom report:

• Customization Services or Platform Services > All tab > Custom Reports Custom List Views filtered by appropriate State

• Purchasing > All tab > Other transaction activity > View transactions > Manage views > Create new view > Step 3: Select filters > State

State values can include: Submitted, Partially Approved, Declined, Draft, Pending

• Custom report writer

• Add a custom view

Report available through:

Customization Services or Platform Services > All tab > Custom Reports

Evidence of control performance should be an annotated report, with comments and follow-up documentation retained.

See review control test.

The test should focus on the activities to prevent inappropriate postings, not simply to see invoices that are posted. This might require specific positive evidence of review.

Unlike most other controls, this control is not specifically designed. Invoice analysis could be used to identify fraud, or unusual activity, or to support other controls. Generally speaking, this control in and of itself would not likely directly address a financial reporting risk.

It's not recommended to just implement a generic "analyze invoices" control with no specific purpose, as it will be hard to demonstrate that this is actually addressing a financial statement risk.

Note that this functionality may be used to mitigate the impact of a control failure elsewhere in the purchase to pay process - to demonstrate that a weakness in control has not had a significant impact. This would be achieved by running reports of invoices in the area impacted by the control weakness. For example, an auditor may have identified a weakness in controls relating to a particular supplier, running reports on all invoices from that supplier could determine if the audit issue was a one-off, or constrain the total amount of the error.

Note that there are several potential controls that could be designed off the back of this report, which can achieve different purposes.

Whatever control is designed, it is important that it is done consistently, with the same criteria applied each time. This prevents the risk that the control becomes overreliant on the ability and experience of the person doing the review.

Purchasing > All > Reports

Several standard reports are available to show a variety of information. Custom reports can be created to pull additional information if required.

Purchasing reports overview

Annotated report, with comments and follow-up documentation retained.

See review control test.

The test should be carefully designed to ensure that the control objective is met - not a general check that some kind of review happened.

Three-way matches are intended to make sure that the goods or services received match up to what was ordered, and that the supplier is invoicing the correct amount for this. If this isn’t the case, the system won’t allow the invoice to be paid until the difference is resolved.

To avoid very small differences preventing invoice payment, set an ‘overrage’ threshold (normally a % or absolute value) that you’re happy to tolerate.

The control therefore stops suppliers being paid before they have supplied what was ordered, and highlights any problems with invoicing before the invoice is paid.

• Tolerance threshold set at level sufficient to allow permissible overages.

• Whether permitted mismatches should be monitored to identify any consistent differences.

• Ability to specify shipping costs separately to the cost of purchase in the matching process so as not to trigger mismatches.

Ensure that the transaction definitions have the following two settings configured:

• Transaction conversion to include only relevant transaction definitions

• Create Policy (Security Configuration tab > Document permissions) should be set to Convert only

For transacting, users will go to Purchasing > All > Transactions > Purchase Order > Convert (on relevant purchase order).

The system does not allow a receipt in excess of the purchase order quantity. Any increase in quantity received would require a new purchase order

Purchasing transaction definitions

Three-way matching configuration set in Purchasing > Purchase Order > Convert (on relevant purchase order).

The system does not allow a receipt in excess of the purchase order quantity. Any increase in quantity received would require a new purchase order.

See configuration control test.

The three-way match functionality should be tested, along with any threshold for acceptance and blocking of invoices above the threshold.

Ensuring that an invoice has a valid accounting assignment in order to be posted reduces the possibility of incorrect postings being made, or fraudulent purchases with no purchase order being hidden.

Configure GL accounts to require certain dimensions, and/or set up smart rules.

• Add a GL account

• Smart rules

Custom list view for GL accounts to include dimension requirement fields.

See configuration test.

The test should ensure the system blocks invoices with invalid accounting assignment.

Where companies operate in markets where local tax rules are complex or rapidly changing, maintaining those tax rules in a core finance system can be hard to do and prone to error. In these cases it might be worthwhile to use local tax engines to calculate taxes and duties.

Are you subject to complex or rapidly changing tax regimes (such as US state & local tax)

There are several options for configuration of automated tax calculations, posting, and reporting. Each organization should review the options relevant to the compliance requirements.

Sales tax, VAT, and GST

Will usually be held in documentation for the tax engine. Users should not have access to manually maintain tax rates maintained by tax engines (as this would allow them to override).

See configuration test (for configuration of tax rates) and access control test (where access should be restricted).

A tax control account reconciliation is important to make sure that the tax balance is correct and/or the tax submission is correct. The former is done by checking the tax balance to any expectations (practicality will prevent a review of all tax transactions), while the latter is done by checking the tax balance to the tax submission, where this is done based on data outside the system.

• What are the thresholds for reconciling items? What will you do if there's for example, a single dollar difference?

• Control account reconciliation is often part of the wider process of balance sheet reconciliations - applying a consistent approach to all reconciliations should be considered.

Configurations will vary per tax solution.

Sales tax, VAT, and GST

Reconciliation documentation, including reconciling items and follow-up.

See reconciliation control test.

This is an important process consideration. In an ideal world, all payments would be generated from Sage Intacct, so that you can be sure that only payments that should be made are made, and that the payments are accurate.

However, in reality you will likely need a manual workaround. The key is to ensure that the workaround is only used in the correct circumstances, and that the system is correctly updated if you use the manual approach.

• Are there different types of payment runs that need to be done?

• Are there circumstances in which payment runs need to be done manually? How will you ensure that these are reflected against the invoice and customer so that there's no duplication?

Accounts Payable > Setup > Configuration > Payment approval settings > Enable AP payments approval

Set up AP payment approvals

System configuration

See configuration control test.

The test should focus on the automatic population of the payment run details, particularly those details relevant to financial reporting.

Control over editing payments is important to prevent fraud. When changes need to be made, it's important to have processes in place to ensure they are done in a controlled way to prevent the use of an alternative method as a way to circumvent this control.

Although it might be that on the surface "no one has access", in some cases, privileged users might have the access required. It is best to restrict this as far as is practical, and monitor those cases where people do need to have the access to ensure it is not abused.

Some organizations will prefer not to allow changes to payments, but reject a payment and require it to be resubmitted, in which case this control would be amended to “Edits to payments are prohibited” and become a preventive, automated control, tested through configuration.

• What's the process if a payment needs to be edited?

• If anyone does have the ability to edit, do you have a control to ensure that this functionality is not used? For example, 'regular' users might not be able to edit line items, but in some cases superusers can.

1. Go to roles or permissions set up page (Company > Admin > Roles or Users > Subscriptions > Permissions)

2. Review existing permissions to allow approval of payments and view of Accounts Payable purchasing transactions, but with no ability to edit or reclassify Accounts Payable bill purchasing supplier invoice transactions or edit supplier records.

Company permissions

System configuration

See configuration/coded control test.

The functionality to be tested is the blocking of changing payment details.

A review of payments that have failed is a straightforward concept, but the important thing is to ensure that the follow-up activities are done properly.

What's the follow-up process for failed payments?

Create a custom report:

Go to Customization Services or Platform Services > All tab > Custom Reports

Custom report writer

Annotated report with evidence of follow-up.

See review test.

The test should focus on the activities to prevent inappropriate payments, not simply to see payments that were unblocked. This might require specific positive evidence of review.

This is an important process consideration. In an ideal world, all payments would be generated from Sage Intacct, so that you can be sure that only payments that should be made are made, and that the payments are accurate.

However, in reality you will likely need a manual workaround. The key is to ensure that the workaround is only used in the correct circumstances, and that the system is correctly updated if you use the manual approach.

• Are there different types of payment runs that need to be done?

• Are there circumstances in which payment runs need to be done manually? How will you ensure that these are reflected against the invoice and customer so that there's no duplication?

Accounts Payable > Setup > Configuration > Payment approval settings > Enable AP payments approval

Set up AP payment approvals

System configuration

See configuration control test.

The test should focus on the automatic population of the payment run details, particularly those details relevant to financial reporting.

Control over editing payments is important to prevent fraud. When changes need to be made, it's important to have processes in place to ensure they are done in a controlled way to prevent the use of an alternative method as a way to circumvent this control.

Although it might be that on the surface "no one has access", in some cases, privileged users might have the access required. It is best to restrict this as far as is practical, and monitor those cases where people do need to have the access to ensure it is not abused.

Some organizations will prefer not to allow changes to payments, but reject a payment and require it to be resubmitted, in which case this control would be amended to “Edits to payments are prohibited” and become a preventive, automated control, tested through configuration.

• What's the process if a payment needs to be edited?

• If anyone does have the ability to edit, do you have a control to ensure that this functionality is not used? For example, 'regular' users might not be able to edit line items, but in some cases superusers can.

1. Go to roles or permissions set up page (Company > Admin > Roles or Users > Subscriptions > Permissions)

2. Review existing permissions to allow approval of payments and view of Accounts Payable purchasing transactions, but with no ability to edit or reclassify Accounts Payable bill purchasing supplier invoice transactions or edit supplier records.

Company permissions

System configuration

See configuration/coded control test.

The functionality to be tested is the blocking of changing payment details.

A review of payments that have failed is a straightforward concept, but the important thing is to ensure that the follow-up activities are done properly.

What's the follow-up process for failed payments?

Create a custom report:

Go to Customization Services or Platform Services > All tab > Custom Reports

Custom report writer

Annotated report with evidence of follow-up.

See review test.

The test should focus on the activities to prevent inappropriate payments, not simply to see payments that were unblocked. This might require specific positive evidence of review.

It's important that an appropriate level of review and approval is sought for supplier contracts that are raised. If this doesn't happen, it's possible that inaccurate purchase orders could be sent to suppliers, or orders raised fraudulently, resulting in financial loss to the company.

Create specific transaction definitions (Purchase requisition workflow) for supplier contracts to be routed for approval.

• Purchasing transaction definitions - Workflow

• Purchasing approvals

Approval workflow audit trail indicating the raisers and approvers.

See workflow control test.

This should be tested in line with a standard workflow process.

This control covers the workflow, not the accuracy of the approvers for each level of approval.

It's important to consider at what level supplier contracts should be approved, by who, and what limits those people should have. This ensures that supplier contracts are properly checked and scrutinized before purchase orders are created against them.

• Should raising and approving of supplier contracts always be segregated, or can approvers also create supplier contracts up to their approval threshold without any need for further approval?

• Is the manual of authority up to date in the system, and has taken account of any staff movements to different roles in the organization?

• Will supplier contract creators be able to select the approver, or will this be predefined in the manual of authority?

• Designate sufficient approvers to cover any work absences

• Will approval for higher value supplier contracts be required from each approver in the chain, or will supplier contracts be sent directly from the raiser to the individual with an approval limit sufficiently high to deal with the supplier contract?

Purchasing approvals

Matrix of authorities contained in system:

Given that supplier contracts are legal documents, consideration should be given to a repository (physical or electronic) that holds the final documents and evidence of approval.

This test, in conjunction with the test of supplier contract approval workflow, should focus on the correctness of the people in the workflow, rather than the configuration of the workflow.

The test is conducted by comparing the list of approvers in the system to the approved list (as opposed to testing that the system correctly routes the contracts, which is what's covered in supplier contract approval workflow).

Limiting the combinations that can be posted reduces the possibility of postings being made to the wrong of entities, profit and cost centers (either deliberately or in error).

• What are the combinations of entity, profit center and cost center that need to be defined?

• Are there any circumstances in which these definitions might need to be changed?

Smart Rules

System posting configuration permissions - Given that contracts are legal documents, consideration should be given to a repository (physical or electronic) that holds the final documents and evidence of approval.

See configuration control test.

The test should focus on the elements of the validation that ensure the integrity of financial reporting.

Restricting the possibility of raising purchase orders more than the contract value acts as a control to ensure that an organization can't order more than has been properly approved, without first adjusting the contract value.

Use Purchasing

System purchase order limit configuration.

See configuration control test.

This test should focus on ensuring the system prevents limits from being exceeded (potentially different limits for different users).

Occasionally contract values are required to be amended as the nature or scope of the contract needs to change or expand. Having a control to re-approve amended contract values allows further purchase orders or call-offs to be raised against it, and ensures that the amendment has been properly scrutinized and approved by the right colleagues.

Purchasing approvals

Review configuration and reporting for supplier contract amendment transaction definition.

See configuration control test.

This test should focus on the requirement for a contract to be approved if amended (subject to thresholds).

What actions are performed when a contract isn't performing as expected. Sometimes this will result in a change or cancellation of a contract, if an alternative supplier is chosen, or the contract is updated to reflect a change in demand / price / schedule.

Go to Purchasing > All > Reports.

Several standard reports are available to show a variety of information. Custom reports can be created to pull more information if needed.

• Purchasing reports overview

• Custom Report Writer

Annotated report. Emails asking for evidence to support contract performance and adequate responses

See review test.

Limiting the combinations that can be posted reduces the possibility of postings being made to the wrong of entities, profit and cost centers (either deliberately or in error).

• What are the combinations of entity, profit center and cost center that need to be defined?

• Are there any circumstances in which these definitions might need to be changed?

Smart Rules

System posting configuration permissions - Given that contracts are legal documents, consideration should be given to a repository (physical or electronic) that holds the final documents and evidence of approval.

See configuration control test.

The test should focus on the elements of the validation that ensure the integrity of financial reporting.

What actions are performed when a contract isn't performing as expected. Sometimes this will result in a change or cancellation of a contract, if an alternative supplier is chosen, or the contract is updated to reflect a change in demand / price / schedule.

Go to Purchasing > All > Reports.

Several standard reports are available to show a variety of information. Custom reports can be created to pull more information if needed.

• Purchasing reports overview

• Custom Report Writer

Annotated report. Emails asking for evidence to support contract performance and adequate responses

See review test.

It's important that an appropriate level of review and approval is sought for purchase orders that are raised. If this doesn't happen, it's possible that inaccurate purchase orders might be sent to suppliers, or orders might be raised fraudulently, resulting in financial loss to the company.

Many Sage Intacct customers are leveraging features such as smart rules and smart events in Customization and Platform Services for the tailored management of master data appropriate for their business needs.

• Smart Rules

• Smart Events

Approval workflow audit trail indicating the raisers and approvers.

See workflow control test.

Although the review of non-sensitive information might not be a key control, it's useful to ensure that the changes are correct. Incorrect changes can lead to confusion.

• How will you analyze the data?

• How much checking will you do to verify the original information?

• Will you be using a sample-based approach? If so, how would you demonstrate that the coverage of your sample was sufficient and appropriately risk-based?

• What are you defining as sensitive data?

Run the ‘Audit History by Object Data Area Report’ filtered by appropriate object data areas.

Use an Audit History report

Report with annotations by the reviewer. Follow up questions should be evidenced. Ensure it is clear what the conclusions were and how they were reached.

See review control test.

The test should focus on how inappropriate changes were identified and follow-up.

A review of sensitive supplier changes should identify both error and fraud. And to be an effective control, a thorough check needs to be done back to the original documentation.

The evidence of the check is key, for example, a positive statement or mark to show that the line has been checked.

• How will you analyze the data?

• How much checking will you do to verify the original information?

• Will you be using a sample-based approach? If so, how would you demonstrate that the coverage of your sample was sufficient and appropriately risk-based?

• What are you defining as sensitive data?

Set up a smart event to send an email to a reviewer when changes are made, and/or run the ‘Audit History by Object Data Area Report’ filtered by appropriate object data areas.

• Use an Audit History report

• Smart Events

Report with annotations by the reviewer. Follow up queries should be evidenced. Ensure it is clear what the conclusions were and how they were reached

See review control test.

The test should focus on how inappropriate changes were identified and followed up.

While many people might have access to edit the non-sensitive master data, the people who can edit sensitive data should be tightly restricted to the minimum practical number.

• How do you define who should have access to edit sensitive data?

• How will you (as a separate control) review who has access to edit sensitive data?

Go to roles or permissions set up page (Company > Admin > Roles or Users > Subscriptions > Permissions) and review existing permissions.

Company permissions

Go to roles or permissions set up page (Company > Admin > Roles or Users > Subscriptions > Permissions) and review existing permissions to ensure access is restricted to specific individuals.

See restricted access test.

This control is needed if you have changes coming into Sage Intacct from other applications, where there's a risk that these changes are not valid or accurate. In this case, it's important that the change is validated to the original request / supplier information, and not just "sense checked".

Are there any controls over the changes in the third-party system, that, in combination with an automated interface, might preclude the need for an additional control? Or is it considered best to review the changes in Sage Intacct?

Go to roles or permissions set up page (Company > Admin > Roles or Users > Subscriptions > Permissions) and review existing permissions.

• Use an Audit History report

• Sage Intacct Developer portal (REST API)

Reviewed listing of changes to supplier master data with follow up to approval elsewhere. This should include a check of accuracy.

See review control test.

The test should focus on how inappropriate changes were identified and followed up.

Most companies want, or are legally obliged, to do compliance checks to ensure they are only working with the suppliers they should be. Integration with external tools enables these checks to be done automatically, but it's important that this fits into the process flow at the right point. The best way of implementing this is to require positive verification that a supplier is acceptable before the supplier is available for use.

• What level of checks need to be done? Anti-bribery, anti-money laundering, etc.

• How is this going to be implemented? Will the supplier be blocked automatically until the check has been done? Or will there be a manual step where someone checks this, but that can be ignored?

Create a ‘Supplier Compliance Check” Checklist

Checklists

Dependent on implementation.

See review control test.

The test should focus on how the checks were carried out and what evidence was inspected.

This control is important to have in place to prevent fraud, but care should be taken as segregation of duties is easily violated if access changes regularly.

In a segregation of duties control, the ideal scenario is that no-one has access to do both of the activities. Even in this case, the control should ideally be operated to ensure this is true on an ongoing basis, because it is easy for someone to be given access inadvertently (or change roles and retain old access). Preventative controls within the access provisioning process should stop this occurring, but because of the risk of fraud it is important to check segregation of duties conflicts regularly.

In the case of conflicts, simple approval of the conflict is not normally sufficient. The 'mitigating controls' should be identified, for example a review of activity logs to ensure the conflict is not abused.

Go to the roles or permissions setup screen (Company > Admin > Roles or Users > Subscriptions > Permissions) and review existing permissions.

• Assign permissions to users

• Permissions report for all users

Conflict report, annotated with mitigating controls.

See segregation of duties test.

This control is important to have in place to prevent fraud, but care should be taken as segregation of duties is easily violated if access changes regularly.

In a segregation of duties control, the ideal scenario is that no-one has access to do both of the activities. Even in this case, the control should ideally be operated to ensure this is true on an ongoing basis, because it is easy for someone to be given access inadvertently (or change roles and retain old access). Preventative controls within the access provisioning process should stop this occurring, but because of the risk of fraud it is important to check segregation of duties conflicts regularly.

In the case of conflicts, simple approval of the conflict is not normally sufficient. The 'mitigating controls' should be identified, for example, a review of activity logs to ensure the conflict is not abused.

Go to roles or permissions setup page (Company > Admin > Roles or Users > Subscriptions > Permissions) and review existing permissions.

• Assign permissions to users

• Permissions report for all users

Conflict report, annotated with mitigating controls.

See segregation of duties test.

This control is important to have in place to prevent fraud, but care should be taken as segregation of duties is easily violated if access changes regularly.

In a segregation of duties control, the ideal scenario is that no-one has access to do both of the activities. Even in this case, the control should ideally be operated to ensure this is true on an ongoing basis, because it is easy for someone to be given access inadvertently (or change roles and retain old access). Preventative controls within the access provisioning process should stop this occurring, but because of the risk of fraud it is important to check segregation of duties conflicts regularly.

In the case of conflicts, simple approval of the conflict is not normally sufficient. The 'mitigating controls' should be identified, for example, a review of activity logs to ensure the conflict is not abused.

Go to roles or permissions setup page (Company > Admin > Roles or Users > Subscriptions > Permissions) and review existing permissions.

• Assign permissions to users

• Permissions report for all users

Conflict report, annotated with mitigating controls.

See segregation of duties test.

This control is important to have in place to prevent fraud, but care should be taken as segregation of duties is easily violated if access changes regularly.

In a segregation of duties control, the ideal scenario is that no-one has access to do both of the activities. Even in this case, the control should ideally be operated to ensure this is true on an ongoing basis, because it is easy for someone to be given access inadvertently (or change roles and retain old access). Preventative controls within the access provisioning process should stop this occurring, but because of the risk of fraud it is important to check segregation of duties conflicts regularly.

In the case of conflicts, simple approval of the conflict is not normally sufficient. The 'mitigating controls' should be identified, for example, a review of activity logs to ensure the conflict is not abused.

Go to roles or permissions setup page (Company > Admin > Roles or Users > Subscriptions > Permissions) and review existing permissions.

• Assign permissions to users

• Permissions report for all users

Conflict report, annotated with mitigating controls.

See segregation of duties test.

Completeness, Existence, Accuracy

Note that completeness and existence will depend on the reviewer's objective. If the review is primarily looking for large balances that might be incorrect, then existence is covered. However, if the review considers large suppliers with unexpectedly low balances, then it might achieve completeness.

The supplier balance review can be more for operational purposes (to ensure you're paying your supplier on time) or can be for financial accuracy purposes (to ensure the invoices on Sage Intacct match what the supplier thinks you owe).

A reconciliation should include evidence of follow-up, perhaps with a threshold defined for the differences that need to be followed up.

Go to AP Ledger report (Accounts Payable > All tab > Reports > AP Ledger) and select relevant variables from available options.

AP Ledger report

Annotated report with evidence of follow-up of unexpected items; or reconciliation of balances to supplier statements.

See review control test.

The test should ensure that the objectives are being met, rather than being a test of a general review.

This control can be useful to identify fraudulent supplier transactions, as the value of transactions might be high but the closing balance might be very small. Otherwise, it might be useful to give you a view of the profile of your suppliers.

Run the AP Ledger report (Accounts Payable > All > Reports > AP Ledger) and select ‘Include zero balance suppliers with activity’

AP Ledger report

Annotated report with evidence of follow-up of unexpected items.

See review control test.

The test should focus on how unusual or inappropriate balances or transactions are identified and followed up.

Valuation, Presentation

This control is to address the risk that a lease, which needs to have proper lease accounting applied to it, is accounted for purely as an expense. There might be certain indicators (such as supplier name) which could be used to help identify such transactions.

Create a supplier dimension group and/or dimension structure with suppliers that meet certain indicators for review. Use this supplier group/structure to review filtered financial reports or GL detail reports.

• Dimension groups

• Dimension structures

Annotated report with evidence of follow-up of unexpected items.

See review control test.

The test should focus on how lease transactions are identified and followed up.

Existence, Accuracy, Ownership

Accounting rules require debit balances with suppliers to be disclosed as debtors rather than offset against other accounts payable balances

1. Create a General Ledger suspense account that's set up to require both Customer and Supplier dimension posting

2. Confirm that both Customer and Supplier dimensions are enabled in both Purchasing and Order Entry

3. Create a ‘Customer Credit Issue’ Order Entry transaction definition (Return type) which posts the credit entry against the suspense account.

4. Create a ‘Customer Credit applied to Supplier’ Purchasing transaction definition (Invoice type) which posts the debit entry against the suspense account

When posting transactions, ensure that each line has both the correct affiliated Customer and Supplier dimension recorded.

Use Purchasing

Annotated report with evidence of follow-up of unexpected items.

See review control test.

The test should focus on how unusual / inappropriate balances or transactions are identified and followed up.

Existence, Accuracy, Valuation

• How often does this need to be updated?

• How do you ensure that all systems are using the same source of information so you do not have discrepancies?

Standard functionality - there's a live link with Oanda that displays in Sage Intacct under Exchange rate type as "Intacct Daily Rate".

About the Intacct daily rate

System configuration

See configuration test.

The test should focus on the automatic population of correct foreign exchange rates.

Existence, Accuracy, Valuation

What's the process and control if a foreign exchange rate does need to be edited?

Additional exchange rates can be added, and then assigned to individual transactions, if necessary.

Exchange rates

System configuration

See configuration test.

The test should focus on the prevention of editing foreign exchange rates on specific transactions.

Existence, Accuracy, Valuation

• Who (if anyone) should have access to edit exchange rate master data?

• What are the controls in place to prevent inappropriate changes to master data?

Go to roles or permissions setup page (Company > Admin > Roles or Users > Subscriptions > Permissions) and review existing permissions.

Company permissions

Go to roles or permissions setup page (Company > Admin > Roles or Users > Subscriptions > Permissions) and review existing permissions to ensure access is restricted to specific individuals.

See restricted access test.

Existence, Accuracy, Valuation

To what level is the reviewer going to perform the review? Is it a sense check, or are they going to manually recalculate (a sample of) balances?

Run the relevant revaluation report in the relevant application (General Ledger/Cash Management/Accounts Payable/Accounts Receivable) > Reports > Revaluation report

Set up for automated journal entry posting, if desired.

Company permissions

Report produced indicating updated valuation of balances. Revaluation report available in the relevant application (General Ledger/Cash Management/Accounts Payable/Accounts Receivable) > Reports > Revaluation report.

Subsequent manual journal posting any differences, approved in automated workflow.

See review control test.

The test should focus on how the accuracy of the revaluation journal was determined (which might include a rough calculation).