Overview
A Payable represents a vendor invoice for goods or services consumed by the business and usually requires payment in a specified timeframe (payment terms). It is used to record the business’ liabilities (debts) to its vendors, and the expense that those items incur. A negative Payable is used as a vendor credit memo to represent a vendor discount or refund.
Note: For information about Header Level Posting (HLP), refer to the Payable Header Level Posting article.
Do you want to:
Create a Payable
-
- Navigate to Accounting Home and click the Create Entries tab. Then, under the Expenses menu, click Payables.
- Click New.
- Enter one of the following required fields:
Note: When using Person Accounts, either the Vendor or Contact field can be populated. However, if you would like the Vendor information to flow through to the Payee field, only the Contact field should be populated.- Vendor (Account)
- Contact
- Employee (Salesforce User)
- Populate other required fields:
- Payee Reference - This is typically the vendor invoice number. The system will not allow the creation of a Payable to the same vendor with a duplicate payee reference.
- Issue Date - This is the vendor’s issue date, and also the date that drives the posting of the expense to the related accounting period.
- Proprietary Payable Number (not required but very useful) - When populated, it will print under Our Reference in the remittance section of the check. If not populated, Our Reference will show the Salesforce auto-generated number.
- Posting Status - Determines the status of the payable. The default status is “Approved,” which indicates the Payable is finalized and can be posted.
Best Practice: It is recommended to have the daily Scheduled Post job created, which provides the ability for all Payables that have a posting status of “Approved” to automatically post based upon the Next Run Date and Preferred Start Time.
- Review and/or modify optional fields:
- Payment Services– this section will display if you have the AP Automation features. For more information, refer to the AP Automation Overview article.
-
- Payment Services Eligible – if you have AP Automation, this checkbox will be selected if the business entity that is related to the selected Ledger has been enrolled in Payment Services.
Note: This checkbox cannot be manually selected.
- Payment Services Eligible – if you have AP Automation, this checkbox will be selected if the business entity that is related to the selected Ledger has been enrolled in Payment Services.
-
- On Hold – select this checkbox to indicate the Payable is on hold and should not be paid. For more information, refer to the On Hold Payables article.
- Early Pay Date – Click the Calendar icon to select a date for early payment. Typically, this is a date that is earlier than the scheduled or agreed-upon date. A discount might be offered if payment is made by this early payment date.
Note: If there are discount terms on the Vendor record, this is calculated as the Issue Date + Payable Discount Days Due. - Payment terms - Upon creation of a payable, if the Payable Days Due field is populating on the related payee account, then the Due Date will be the issue date plus that number. This automation only happens when a Payable is created and not when it is edited.
- Discount Amount - If the related Payee has early payment discount terms set up on their account, then this will flow through to the Discount Amount field. If this Payable is paid within these terms, then the discount will be applied and the difference will flow through to the discount GL Account that is set up in the Default GL Accounts screen.
- Due Date - Upon creation, the Due Date field on the Payable will populate based upon the formula for the Due Date, which is calculated as: Issue Date (from Payable) + Payable Days Due [f this field was populated on the Account, the Contact or Employee (User)] = Due Date.
Note: Upon saving, if the Payable Days Due field was not populated, the Due Date on the Payable will be the same as the Issue Date. - Accounting Period - Defaults to the period related to the issue date.
- Payment Services– this section will display if you have the AP Automation features. For more information, refer to the AP Automation Overview article.
- Click Save.
Create Payable Lines
The Advanced Line Manager (ALM) functionality that includes the data grid with expand/collapse drawer capabilities is available when creating a Payable Line.
Note: For information about the Advanced Line Manager, including functionality, refer to the Advanced Line Manager article.
- If you already have a Payable displayed, continue with step 2. Otherwise, navigate to Accounting Home and click the Create Entries tab. Then, under the Expenses menu, click Payables. Do the following:
- Select a list view (other than the Recently Viewed list view).
- Select a desired Payable. Then, continue with step 2.
- The initial row displays in the expand/collapse data grid. The Date field automatically populates from the Issue Date on the Payable record.
Note: Click here to view the above image in full screen.
Note: If an amount is entered in the Total field, after you click Save, this same amount will automatically populate in the Unit Cost field and the Quantity will be 1. If the Total field is left blank, the Unit Cost is required.
The amount that is entered in the Unit Cost field multiplied by the Quantity plus the Tax Amount will determine the Total. If the Total equals this equation (Quantity x Unit Cost + Tax Amount = Total), then the Unit Cost and the Total can be entered simultaneously. If the Quantity field is blank, upon saving, a Quantity of one will auto-populate for the line.
Best Practice: To ensure that the correct Quantity and Unit Cost are reflected on the Payable, it is strongly recommended that the Quantity and Unit Cost be entered on the Payable Line. If only the Total amount is entered, the Quantity will always be set to 1 once Save is clicked.
Note: If an Expense GL Account has been included on the customer Account record or a Product was entered, which includes an Expense GL Account, this GL Account will automatically populate in the Expense GL Account field on the Payable Line. Otherwise, the Expense GL Account is a required field. - (Optional) Complete the following fields, as necessary.
- Product
- Quantity
- Total
- Tax Amount - populates automatically upon saving the row. However, you can click the Pencil icon to modify the Tax Amount, if necessary.
- Tax Group - click the Lookup icon to search for and select the Tax Group.
Note: If Header Level Posting (HLP) is enabled and using AS Native Tax calculation, the Tax Group field is available. For information about Tax Groups, refer to the Set up AS Native Tax article. - Project/Project Task
Note: If a Project is selected, a Project Task must also be selected. - GL Variable 1-4
- Click Save.
- (Optional) Click Add Row to include an additional row(s).
With Header Level Posting (HLP) enabled, if tax was calculated, the Tax Amount displays as part of the Payable Line.
With Line Level Posting (LLP) enabled, if tax was calculated, the Tax Amount displays as a separate Payable Line.
Note: If utilizing an approval process, the Posting Status must be “Approved” in order to post.
Note: If the daily Scheduled Post job has been created, all Payables that have a posting status of “Approved” will automatically post based upon the Next Run Date and Preferred Start Time.
Clone a Payable
The Payable Clone w/Lines feature provides an efficient way to duplicate a previously entered Payable.
Before cloning a Payable, you might want to check the fields that will be included on the clone by reviewing the Payable fields for Clone and Payable Line fields for Clone field sets to make sure only the fields that you want will be included. This allows you to have more control over exactly which fields will be included on the cloned version of a Payable. For more information, refer to the Edit a Field Set article, where you can edit a field set to add or remove a field(s).
Note: If you remove a required field from a field set, when the Payable is cloned, all required fields will still be included on the clone (even if they were removed from the field set).
- Navigate to Accounting Home and click the Create Entries tab. Then, under the Expenses menu, click Payables.
- Select a list view, such as All. Typically, you want to select a list view other than Recently Viewed.
- Click the Payable Name that you want to clone.
- Click Clone w/ Lines. The Clone Payable intermediate screen displays.
- Modify the Issue Date, if necessary.
Note: If the Payable was made to a Contact or Employee, in addition to the Issue Date, the Due Date displays. The Due Date is calculated using the same length of the payment term as the original Payable. You can modify the Due Date, if necessary. - Click Clone Payable.
- On the Payable Edit dialog box, update the Payable information as needed.
- Click Save.
Notes:
- For every Payable posted, the GL Account credited will always be the system AP Control GL Account entered in the Default GL Accounts. Once transactions are posted to this AP Control GL Account, it cannot be changed in Default GL Accounts unless those transactions are deleted.
- Payable Line limits are documented in the Post/Unpost Limits article. If you have the Large Data Optimizer feature enabled, refer to the Large Data Optimizer article for line limit information.
- Payables can be set up to use Salesforce Approvals.
____________________
Summer '24 Release
The On Hold field was added.
____________________
Spring '24 Release
- Advanced Line Manager (ALM) has been added to create Payable Lines. Additionally, if using the AP Automation features with an Email Service created, invoices will display below the ALM in the Related Documents carousel to easily add as Payable Lines.
- The Large Data Optimizer feature is available. For more information, refer to the Large Data Optimizer article.
Comments
17 comments
Just to verify that I am reading correctly: If a product is entered on an AP line (rather than being transferred from a PO), the Expense GL Account is still going to be populated from the Account default expense account instead of the product expense account?
yes this is correct. If an AP is not created form a PO the default expense GL Account will be that set on the Account. If an AP is created from a PO the Default expense will be that of the product. You can overide the default in either use case.
Hi Tony, thanks for your response. I'm not sure the most recent release conforms to your answer.
In my testing of Financial Suite 3.7.2/ERP 3.5 (not sure if it is the same in other releases), if I add a product directly to an AP line, it is setting the expense GL Account based on the default expense GL account set on the vendor Account record and not based on the expense GL Account set on the product regardless of whether the product is marked as an Inventory product or not.
Where if i put the inventory product on a PO and then create a payable from the PO, the product is - correctly - expensed to the Expense GL Account specified on the product.
It seems that if you enter an AP with an error, pay it, you need to delete the Cash Disbursement to correct the error. This means that you lose the history of the voided check, unless you manually create a new Cash Disbursement with the same check number and mark it void.
Is there a better way to handle this where the original voided check (Cash Disbursement) is retained?
Chad,
If you want to maintain al of the history you really need to book new adjusting entries. You can certainly void the cash disbursement, create a credit memo, apply it to the AP document and create a new AP record.
Thanks,
Tony
It would be helpful if the GL Account Variables and GL Account # could be changed on A/P lines without having to delete cash disbursement batch (which could include dozens of checks), delete the cash disbursement, un-post the A/P entry, make the quick GL Variable change, re-post the A/P, re-pay the item, TRY to recreate a cash disbursement batch (good luck easily doing that when you deleted a batch that had dozens of checks in it), re-post the cash disbursement batch on the original date. And if the bank rec has been completed already - you have to undo all of that work too. OMG - two hours of work to make a quick fix to GL Variable or GL acdount posting error.
The GL Variable or GL# doesn't change the $$ of the entry, the date it was posted, the date it was paid, the check number or cash disbursement batch it was posted in, or the bank rec it was included on. Only the sub-classifications for reporting.
When many employees are entering POs, Invoices, etc. that eventually hit A/P, sometimes things get into wrong departments or GL Accounts. The error isn't always evident until someone at a higher level is reviewing the F/S at month-end. It's virtually impossible to make corrections easily, with out creating a ton of Journal Entries or undoing an entire month's work of work.
Could this please be incorporated into a future release of Accounting Seed?
Hi Jeanae,
I understand your frustration around unposting and updating the variables, but this security is build in place so that users cannot easily change transactions, which will in turn affect all of the financial reports.
An easier way to adjust a variable mistake is through a journal entry. Debit and Credit the same GL account, but just update the variable. The transaction will still have the incorrect variable tagged, but the reporting will be correct.
Feel free to submit a ticket to support with any other questions.
Also, how can we revise standard GL reports to actually show transaction descriptions and other useful info other than transaction numbers? Our GL is so large, we have to download the standard GL Activity report into Excel and there is not description that comes through, and since you can't drill down from the excel report, they are really of no value. Thanks
Hi Jeanae,
Depending on the report that you are running, try adding the "note" field as a column. This includes some helpful info like check numbers and references depending on which transaction is being reported on.
If you would like to see other specific fields, these could always be pulled over to the transaction object with a formula field.
Hi Jeanae,
If you know how to create a custom report type, you can create a custom report type that pulls in ALL the good data from all of the related records using the edit layout feature, and then just use that as the basis for your GL reports instead of the standard transaction report type.
If you don't, I can point you in the right direction, or set one up for you depending on your level of comfort with the system.
I can be reached at rebeccaralls (at) gmail (dot) com.
Ryan - I understand the point about security in your May 24, 2017 post ("...this security is build in place so that users cannot easily change transactions") but each organization using Accounting Seed probably has slightly different needs for that kind of locking and it would be great if Accounting Seed would accommodate that variability.
For example, AS could enable a permission which would enable a super user to, perhaps, check a box, edit the values in a bunch of GLAVs, GL Accounts, Accounts, Projects and Project Tasks, then uncheck that box to prevent even that super user from editing those values. In our case, for example, we would like to reassign Project and Project Task to a lot of records, and will probably want to again as our thinking about the schema of our Projects and Project Tasks continues to evolve.
I would concur with Lloyd. The determination of what can be changed and by whom would work better for the users if this were determined through user permissions versus hard coded. I understand certain fields can not be changed, but Projects/Project Tasks, GL Variables, GL Accounts on Paybles, etc. sometimes need correcting due to data entry errors and it is difficult to do this in many cases in the Accounting Seed product.
Just as a counterpoint, I worked with Oracle - where you couldn't change *anything* after it had been posted for a couple hours and the only way to fix anything was through a journal entry - so I really appreciate that - while sometimes arduous - it is *possible* to go back and fix stuff in the original transactions.
I tend to agree with Accounting Seed's current format which ensures that anything that affects/can change your financial reports is locked when the record is posted and the period is closed. Changing GL Accounts and GLAV Assignments will change your financial reports, and so it makes sense to me that there are a couple layers of security around changing these items once a record is posted and the period is closed.
That said, there are a couple things that could really help curb some frustration with the ability to go back and fix errors - because everyone makes errors.
Under "Please Note" above this doc says:
"After an account payable record has been paid, the system will not allow it to be un-posted. In order to un-post it, the associated cash disbursement must first be un-posted and deleted. This is a safety feature so that account payable amounts can't be edited after the record has been paid."
However, it seems like we used to be able to delete the APD record, leaving the Cash Disbursement and Payable intact, unpost the Payable to edit something, repost it and then reapply the Cash Disbursement. If that isn't possible, I would like to suggest that this capability be added. It would still be very safe, since all Cash Disbursements are ultimately reconciled to the bank statement.
Craeted a Payable for a person Account . And the Payee field didn't populate.
Hi Richa,
When creating a Payable for a Person Account, the lookup field that should be populated is not the Account field but instead the Contact field.
Thanks
Thank you so much.
Please sign in to leave a comment.