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.
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 the System Defaults:
- 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 (if this field was populated on the Account or the Contact) = 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.
-
Click Save.
-
Enter Payable lines by clicking New or Mass Add/Edit Rows.
When a new line is added (using the New button or Mass Add/Edit Rows), the Date field for the line will automatically populate with the Issue Date from the Payable header record. The Date field can be modified to select a different date, if necessary.
-
Enter the following required fields:
-
Unit Cost - This is the cost per unit.
Important: The Total field is recommended to be read-only on the user interface. 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.
The Total field is controlled by Field Level Security (FLS). Therefore depending upon the permissions granted through a user’s Profile and/or Permission Set(s), the Total field might be editable. However, editing this field directly in the UI is NOT recommended.
-
Expense GL Account - If the payee has a Default Expense GL account setup on their account profile, then this will populate here, but it can be overridden. This field is named Expense GL Account, but note that any GL account can be populated here and a debit entry will be made to it upon posting.
-
Unit Cost - This is the cost per unit.
- Complete additional fields as needed such as Product, Project, Project Task, GL Variables.
Note: If calculating tax using AS Native Tax HLP, then populate the Tax Group field on the Payable Line. For information about Tax Groups refer to the Set up Accounting Seed (AS) Native Tax article. -
From the Mass Add/Edit Rows page, click one of the following:
-
- Save & Refresh - Save your changes and refresh the screen to display the Mass Add/Edit Rows with your changes.
- Save & Complete - Save your changes and return to the Payable screen.
- Save & Post - Save your changes and post transactions to the General Ledger.
- Save & New - Save your changes and display the New Payable dialog box to create a new Payable.
-
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.
- 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.
- Payables can be set up to use Salesforce Approvals.
____________________
Summer '23 Preview 1 Release
- If you create Payables for Contacts, the Payable Days Due field is now available on the Contacts.
____________________
Winter '23 Release
With the Winter '23 release, Total and Unit Cost can be entered at the same time.
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.